[Sammelthread] ZFS Stammtisch

gea schrieb:
OmniOS unterstützt zwar SMB 3.02, nicht aber alle Apple spezifischen Erweiterungen
vgl Feature #11017: Support Apple FULL_SYNC feature - illumos gate - illumos

Im Moment sehe ich nur zwei Optionen für OmniOS
1. AFP via netatalk (end of life)
2. SAMBA, Bug #10577: avahi/dns-sd not propagating services using port - OpenIndiana Distribution - illumos


Ich habe mal ein Feature Request Ticket angelegt. Vielleicht kommt da was.
Feature #12039: Kernelbased SMB should support Apple Timemachine - site - illumos
Zum Vergrößern anklicken....

Danke! Das Advertising ist kein Problem (kann man umgehen, in dem man man mountet und dann auswählt) - ich nahm an, da die Apple Dateisystemoption nachträglich noch rein kamen, dass dadurch insbesondere auch TM funktionieren müsste, dem ist aber wohl nicht so.

Danke für Deinen Einsatz hinsichtlich des Tickets!
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
gravis schrieb:
Danke das Problem, lag wohl an der ESX Remotekonsole. Ich habe es nun mit leeren Passwort hinbekommen und neu gesetzt.
Zum Vergrößern anklicken....

Verstehe ich nicht. Was war das Problem? r o t und Eingabetaste sind alles keine Sonderzeichen. Ich zumindest hatte mit der Konsole noch nie Probleme.
 
Hallo Zusammen,

ich habe eine etwas merkwürdige Problematik mit einem Share meines Home-Servers (siehe Signatur) den ich an mein Windows 10 per SMB gemounted habe als Laufwerk.
Im Windows selbst wird mir der Inhalt des Shares so weit ich es sehen kann immer korrekt angezeigt.
Ich habe auch Zugriff auf die vorigen Versionen der Snaps, und kann diese auch herstellen.

Wenn ich allerdings in meinem DMS PaperOffice, welchem das Share Laufwerk (P:\) im Windows eingebunden wurde, die Ordnerstruktur neu einlese, werden mir diverse Ordner multipel Dupliziert angezeigt.

Ich konnte testen das wenn ich den Share, mit selben Inhalt auf meinem Qnap bereitstelle, das diese problematik mit den Duplikaten nicht auftritt.
Wäre diese Problematik ggf. ein Grund auf das aktuelle OmniOS zu wechseln?
Könnte es ggf. an einer bestimmten Einstellung zum ZFS / SMB Freigabe liegen?

Wenn ich so nachdenke hatte ich es schon einmal, das auf einem Android Gerät ein Share meines Homeservers diese Problematik von mehrfach angezeigten Ordnern gebracht hatte.
Dies hatte ich seinerzeit allerdings nicht weiter verfolgt.

Zufällig jemand eine Idee hierzu, könnte es evtl. an der SMB version des Solaris 11.4 liegen?
Grüße

Elektromat
 
Ich denke nicht, dass es an der SMB Version liegt (Solaris 11.4 hat SMB v3.1, OmniOS v3.02) sondern eher daran, dass entweder eine ganz spezielle Windows/ SAMBA Funktionalität benutzt wird oder aber daran, dass manche Share Features unterschiedlich voreingestellt sind, z.B. das Locking Verhalten (wird über die ZFS Eigenschaft nbmand on/off eingestellt, siehe napp-it Menü Dateisysteme) oder eine andere smb oplock Einstellung erwartet wird (Menü Services > SMB > Properties).

Solaris SMB und OmniOS SMB (kernelbasierter Server) haben ansonst zwar die gleichen OpenSolaris Wurzeln, haben sich aber seit 10 Jahren eigenständig weiterentwickelt. Kann also schon sein, dass die sich unterschiedlich verhalten.
 
Hallo, sind eigentlich die ZFS-Versionen von FreeNAS und XigmaNAS miteinander kompatibel? Also ich meine jetzt in unterschiedlichen Versionen...

Ich habe aktuell FreeNAS stable 11 im Einsatz. Wenn ich jetzt auf FreeNAS stable 11.2 oder 11.3 beta upgrade, kann dann so ein ZFS-Pool trotzdem von (der aktuellen stable) XigmaNAS noch gelesen werden? Oder funktioniert das nur mit älteren FreeNAS-ZFS-Versionen?
 
FreeNAS und XigmaNAS sind webbasierte NAS Managementtools die jeweils mit einer bestimmten Version von Free-BSD kommen. Haben beide die gleiche Free-BSD Version ist das darin enthaltene Open-ZFS featuremäßig identisch. Ist bei einem ein neueres Free-BSD dabei, geht der Pool Austausch nur zum neueren. Ältere Open-ZFS Versionen können teilweise einen Pool noch readonly importieren. Bei manchen Features geht ein Import gar nicht mehr (das neue/künftige Open-ZFS Features encryption ist dafür ein Beispiel)
 
FreeNAS 11.2 basiert auf FreeBSD 11.2.

Das aktuelle XigmaNAS 12.1 basiert anscheinend auf FreeBSD 12.1 Release p0.

Also kann ich später problemlos zu XigmaNAS wechseln, wenn ich mein FreeNAS jetzt auf 11.2 update.
 
Kann man das napp-it auf der Seite nicht mehr downloaden? Ich sehe da keine Links mehr. :(
 
Eine Frage bezüglich Datensicherheit/Datenintegrität:

Folgendes Szenario:
Ein ZFS Pool (raidz2) als Dateisystem für eine Vdisk einer Debian VM. Die vdisk wird ext4 formatiert.

* Inwieweit profitiert diese vdisk dann von den Vorteilen des darunterliegenden ZFS, vor allem was die Datenintegrität?

* Kann ich von diesem ZFS storage snapshots anfertigen und davon ausgehen, dass die vdisk in einem sinnvollen/gültigen Zustand ist, wenn die VM während der Erstellung des Snapshots läuft?
 
Aus Sicht von ZFS ist die VM eine Datei. Deren Integrität wird durch Prüfsummen garantiert und eventuelle Prüfsummenfehler automatisch aus Redundanz korrigiert. Außerdem gibt es als Extra überragendes rambasiertes Schreib-Lesecaching, spezielle/schnellere vdev und sicheres Sync Write als Option.

Man kann Snapshots des ZFS Dateisystems anlegen. Damit wird der Datenstand zum Zeitpunkt des Snaps eingefroren.

Jetzt zum ABER!

Ein Snapshot entspricht einem Datenstand den man hätte, wenn man einfach den Stecker zieht. Manche VMs vertragen das gut, andere sind dann korrupt. Das hängt dann aber ausschließlich an der VM.

ZFS nutzt ausgiebig RAM als Schreibcache. Eine Schreibaktion einer VM wird dabei sofort bestätigt, ohne dass die Daten auf Platte sind. Bei atomaren Schreibaktionen wie Daten aktualisieren und dann Metadaten updaten kann es daher passieren dass die VM mit ext4 korrupt ist - auch wenn das ZFS gar nicht mitbekommt und für sich immer valide ist (wegen CopyOnWrite).

Insgesamt gibt es zwei Sachen zum Beachten wenn man sicheren VM Storage möchte.

1. Um einen sicher konsistenten Stand einer VM zu haben, muss der Snapshot im Poweroff der VM passieren oder aber die VM muss kurz angehalten werden. VM Backupprogramme machen das auch so. Man kann das als Pre-Aktion vor/nach einem Snapshot erledigen. Noch besser kann das z.B. ESXi mit hot memory Snapshots die sogar den aktuellen RAM Status sichern. Damit kann man Hot auf eine laufende VM zurück. Hierzu wird ein ESXi Hot Snap erstellt, dann ein ZFS Snap der den enthält und anschließend wird der ESXi Snap wieder gelöscht um keine Performanceprobleme zu erhalten. Nach einem ZFS Rollback kann man dann auf den ESXi Hotsnap zurück. In meinem Napp-it habe ich so eine Funktion integriert. Kann man aber auch ansonst durch ein Script + SSH erreichen.

2. VMs sind darauf angewiesen, dass ein bestätigtes Write auf Platte ist. ZFS Dateisysteme mit VMs sollten daher immer im sync write Modus betrieben werden. Die Performanceeinbußen von sync write lassen sich durch geeignete Slogs ausgleichen (Intel Optane, WD SS 530 etc)

Wäre die Debian VM auch auf ZFS und würde man sowohl in Debian sync write aktivieren wie auch auf dem zugrundeliegenden Storage wäre die Gefahr eines korrupten VM Dateisystems weitestgehend gebannt. Das Problem sind "alte" Dateisysteme in den VMs und diverse Write Caching Optionen.
 
Zuletzt bearbeitet:
gibt es eigentlich irgendwelche bekannten Probleme mit Pools aus nur einer HDD?
Mir sind jetzt innerhalb von 2 Tagen 3 Pools ausgestiegen mit IO Error. Unterschiedliche Kabel an unterschiedlichen Controllern. Einen Hardwaredefekt bei allen 3 HDDs kann ich mir nicht vorstellen...
 
Am gleichen Server? Netzteil Probleme? Mainboard Treffer?
Unabhängig davon, dass Single nicht best-practice ist, glaube ich auch nicht an dreifaches HDD Versagen in wenigen Tagen.
 
Ja,
ich habe jetzt mal auf die neueste Version e geupdatet. Dort heißt es

Fixes to support for large (> 2TB) USB hard disks.
Zum Vergrößern anklicken....

Eine der Platten ist eine 4TB USB HDD. Allerdings hatte ich eigentlich bis dato gar keine Probleme damit.

Smart Fehler hatte die HDD auch keine als ich sie mal an meinem Laptop angeschlossen habe um das zu testen grade eben.

Hat sich jetzt wieder importieren lassen der Pool der drauf war, mache grad mal einen scrub und gucke ob Fehler gefunden werden.
Obendrein ist die HDD maximal nen halbes Jahr alt.. Denke nicht dass es an der Platte selbst liegt daher.

Die rpool SSD habe ich auch mal gescannt mit einem Scrub, dort waren auch keine Fehler.
 
Zuletzt bearbeitet:
Das Update hat den Fehler zumindest mit der USB HDD behoben. Ein Scrub hat keinen Fehler mehr gefunden und alle Daten sind noch da.
 
Moin,

ist das richtig, dass das OmniOS "nur" 32Bit ist? Die VM steht auf 64Bit.

Habe die zfs_vsan_omni032_esxi6v1.ova installiert.
 
OmniOS ist grundsätzlich 64 bit, allerdings gibt es noch einige packages in 32 bit, die noch nicht auf 64 migriert worden sind. Man ist aber dabei: OmniOS Community Edition r151030 LTS "Several 32-bit only packages have been moved to 64-bit only."

(das "32" im Dateinamen ist release 32, nicht 32 bit)
 
Mein installiertes aus dem Template ist kein 64Bit.

Siehe Screenshot:

omnios.png
 
OmniOS ist seit ewigen Zeiten ein 64 Bit OS auf dem aber manche ältere 32Bit Software lauffähig ist.
Bei der Start Meldung geht es darum, dass die Omnios Version 151032 installiert ist

(Hostname ist napp-it-32 und OS Release ist 151032)
 
Ich denke, dass die Verwirrung auf Grund fehlendem x86_64 bei uname -m auftauchte. Auch getconf LONG_BIT liefert 32.
Unter Solaris kannst Du es zuverlässig bestimmen mittels isainfo -kv
 
Hallo Zusammen,

ich stehe aktuell vor einer Problematik mit meinen Snapshots.
Aktuell verwende ich folgendes Setup mit Napp-It 19.06f Pro (siehe unten)

Aus mir nicht erklärbarem Grund werden wohl keine Snapshots gelöscht, was zur Folge hat das der Speicherplatz auf dem entsprechenden pool / ZFS Filesystem immer geringer wird.

Ich habe all meine Snaps über Autosnap Jobs wie folgt konfiguriert nach folgendem Beispiel:

2019-12-11 18_04_27-solaris __ ZFS appliance.jpg

Ich wurde erst darauf aufmerksam als mir heute massenweise Push nachrichten erzeugt wurden, mit dem Inhalt Low CAP ALERT 15%.
Der Auto Service Job läuft also zumindest korrekt, und das alle 5 Minuten.

Wenn ich die Konfig richtig deute sollte steht es doch auf keep 2; delete zero also alle die keine Änderung haben, und hld 8 was doch bedeuten sollte das jedes 8te Snap auf hold gesetzt wird.
Oder habe ich da etwas falsch verstanden?

Ich habe schon ein paar Snaps entfernt, das zumindest die Warnung nicht mehr kommt.
Für Hilfestellung hierzu wäre ich dankbar.

Grüße

Elektromat
 
Zuletzt bearbeitet:
Danke für deine schnelle Rückmeldung.
Hab eben das Update auf die v19 Dev geladen und angewendet.
Muss ich die AutoJobs neu anlegen? Oder funktioniert es mit den bestehenden?

Nur das ich es auch richtig verstehe, das keep 2 bedeutet es das die Snaps vorgenommen werden nach entsprechendem Zeitplan, und dann nur zwei aus diesem Job bestehend bleiben?
 
Das aktualisierte Autosnap Script sollte die alten Angaben korrekt abarbeiten

Zu autosnap in napp-it:
ZFS erlaubt problemfrei auch mehrere zehntausend Snaps (Dateiversionen). Napp-it unterscheidet anhand des Namens Replikations und normale Snaps. Beim Anlegen eines normalen Snap-Jobs kann man neben dem Zeitplan folgendes angeben:

delzero:
Wird das aktiviert, so werden alle Snaps mit used=0 (identischer Datenstand zum vorherigen Snap) gelöscht - bis auf den neuesten Snap mit used=0. Der darf nicht gelöscht werden weil ansonst eine Replikation ohne Änderung nicht mehr funktionieren würde. Diese Funktion dient nur der Übersichtlichkeit damit man nicht endlos identische Vorversionen/Snaps angeboten bekommt.

keep und hold:
Ein Snap wird nur gelöscht, wenn sowohl die keep wie auch die hold Einstellung das erlaubt.

keep:
Anzahl der Snaps die per Job behalten werden.

hold (optional):
Snaps werden nur gelöscht wenn Sie älter hold sind (in Tagen)

Beispiel:
Wird ein autosnap stündlich ausgeführt und steht keep=24 und hold =""
Für den aktuellen Tag wird ein stündlicher Snap bereitgestellt. Ältere werden gelöscht.

Wird ein autosnap stündlich ausgeführt und steht keep=24 und hold ="2"
Für die letzten beiden Tage wird ein stündlicher Snap bereitgestellt. Ältere werden gelöscht.
Die keep Angabe wird praktisch ignoriert.
 
Verzeiht mir bitte, wenn das Thema schon diskutiert wurde, aber hat schon jemand einen ZPOOL mit Geli auf die native Verschlüsselung von ZFS0.8.x umgezogen? Gibt es da überhaupt einen Migrationspfad oder sollte ich die Daten lieber rüberkopieren?

Habe aktuell FreeNAS im Einsatz, will allerdings auf Ubuntu Server umziehen.
 
Da gibt es keinen Migrationspfad. zfs send/receive sollte funktionieren und gleichzeitig Attribute wie Freigaben und Berechtigungen übernehmen.
 
Ich benutze in omnios lx zones. Seit dem neusten Update habe ich aber ein Problem:
Ich verwende eine lx zone mit ubuntu16.04 und trage manuell in der entsprchenden zone unter etc/resolv.conf meinen dns server ein denn anders funktioniert es nicht.
Jetzt überschreibt mir omnios bei jedem neustart der zone diese Datei aber mit dem sinnbefreiten Inhalt von:

"# AUTOMATIC ZONE CONFIG
search
"
Habe in der zone.cfg auch schon

"add attr
set name=resolvers
set type=string
set value=8.8.8.8
end
" rausgenommen, dennoch wird es jedesmal überschrieben. Was kann man da machen?
Von mir aus kann er die Datei auch jedesmal überschreiben solange er dies mit sinnvollem Inhalt tut.
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
821
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
540
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
495
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
9K
gea
G
AliManali
*erledigt* Perc H310 flashen
Antworten
2
Aufrufe
282
AliManali
AliManali
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh