[Sammelthread] ZFS Stammtisch

[HansBohne]

Hmmm ich habe damals von gecryptetem OpenZFS 0.8 also glaub der ersten die das hatte dann auf eine "final" umgestiegen das hat damals problemlos geklappt aber glaube für jede Version auf jede glaube das wird dir niemand zu 100% sagen können.

Kannst ja evtl einen Test machen? also eine Dummy-Datei als zfs device nutzen darauf auf dem Quellsystem ein genauso wie das andere gecryptete ZFS draufmachen und dann schauen ob das auf dem Zielsystem aufmachen und beschrieben kannst. Dafür reicht ja ein 100 MB File (zumindest wenn es Linux / Freebsd ist geht das ja einfach)

 

[Rach78]

Also mein Stand war noch bix zu einer bestimmten Version war es zwischen Solaris und dem Rest kompatibel. Dann kamen die Feature Flags, dann war es mit Solaris nicht mehr kompatibel, aber alles andere untereinander. Aber das scheint ja nun auch nicht mehr so zu sein...
Wieso kann es nicht einfach eine Versionsnummer geben und wenn das OS diese Nummer dann hat oder höher kann man den Pool importieren und nutzen.

Solaris <-> OpenZFS, Illumos ZFS: nein, nie

Also Illumos ZFS ist ungleich OpenZFS?

Ich dachte Illumos hängt immer nur bisschen hinterher aber ansonsten ist das dasselbe..

 

[gea]

Also mein Stand war noch bix zu einer bestimmten Version war es zwischen Solaris und dem Rest kompatibel. Dann kamen die Feature Flags, dann war es mit Solaris nicht mehr kompatibel, aber alles andere untereinander. Aber das scheint ja nun auch nicht mehr so zu sein...
Wieso kann es nicht einfach eine Versionsnummer geben und wenn das OS diese Nummer dann hat oder höher kann man den Pool importieren und nutzen.


Also Illumos ZFS ist ungleich OpenZFS?

Ich dachte Illumos hängt immer nur bisschen hinterher aber ansonsten ist das dasselbe..

OpenZFS war bis 2019 Illumos ZFS, ab dann wurden beide in getrennten Repositories von eigenen Teams gepflegt. Illumos ZFS ist sehr konservativ was die Übernahme neuer OpenZFS Features angeht während in OpenZFS Neues sehr schnell landet, auch wenn es noch nicht voll getestet ist. Fast Dedup z.B. kommt jetzt erst in Illumos ZFS.


Pool Austausch zwischen OpenZFS Releases und/oder Illumos ZFS höngt daran ob das ZielOS die jeweiligen Features unterstützt, einen neuen OpenZFS Pool kann man oft auch nicht in einem älteren OpenZFS ohne Support für ein Feature öffnen.

Vorteil ist natürlich dass in Illumos ZFS in vielen Jahren nicht soviel Probleme waren wie in OpenZFS teils in einem Jahr.

 

[HansBohne]

Naja OpenZFS wird halt von extrem vielen genutzt da findet man halt Sachen die praktisch nur in 0,000001% der Fälle auftreten.

Meine es wurden doch schon 1 oder 2 Fehler durch OpenZFS entdeckt die seit Jahrzehnten im ZFS Code waren.

 

[Rach78]

Pool Austausch zwischen OpenZFS Releases und/oder Illumos ZFS höngt daran ob das ZielOS die jeweiligen Features unterstützt

Sind diese Features denn identisch oder werden hier einfach Features die das gleiche machen parallel entwickelt und sind dann zueinander inkompatibel?
Ich habe ja einen OmniOS ZFS Pool und diesen will ich einfach in Proxmox, TrueNAS beispielsweise öffnen mounten, zumindest lesen.

Re: [discuss] ZFS native encryption status

www.mail-archive.com

Illumos had ported the zfs encryption prior to this bug fix, so we still use
the older incompatible format.

Heißt das das damit OmniOS jetzt ein anderes encryption benutzt als OpenZFS?

 

[gea]

OpenZFS kann einen unverschlüsselten OmniOS Pool problemlos öffnen, da alle OmniOS Features unterstützt sind. Andersrum kann es Probleme machen, z.B. ein OpenZFS Pool mit aktiviertem Raid-Z Expansion kann in OmniOS nicht geöffnet werden, da es das Feature da noch nicht gibt.

Verschlüssellung ist ein Sonderfall. Da gab es in OpenZFS ein Update das nicht rückwärtskompatibel war und einen Pool move mit Illumos ZFS oder älterem OpenZFS verhindern kann. Normales zfs send ist dann der Workaround.

Insgesamt ist ZFS egal auf welcher Plattform nur aufwärtskompatibel (neues liest älteres). Migration benötigt ansonst zfs send.

Beitrag automatisch zusammengeführt: Heute um 00:12

Naja OpenZFS wird halt von extrem vielen genutzt da findet man halt Sachen die praktisch nur in 0,000001% der Fälle auftreten.

Meine es wurden doch schon 1 oder 2 Fehler durch OpenZFS entdeckt die seit Jahrzehnten im ZFS Code waren.

Prinzipiell richtig, dennoch gab es in den letzten Jahren mehrfach Fälle von Datenverlust in OpenZFS durch neuere Features die in Illumos ZFS keine Auswirkung hatten - weil es das auslösende Feature nicht gab oder weil das Problem nur mit einer bestimten Kombination OpenZFS Release auf einem der vielen Linux Distributionen auftrat. OpenZFS gleicht da mehr einem Zoo mit den vielen Distributionen, jede mit einem anderen ZFS Stand und niemand weiss, ist dieses oder jenes das Zuverlässigere, hilft ein Update oder nicht.

Bei Illumos gibt es halt genau ein ZFS auf genau einem OS das vom Anbeginn der Zeit nur auf ZFS ausgelegt war, gepflegt von einem Kern-Team das nur Code integriert der mehrere extra Tests durchlaufen hat. Ist ähnlich bei Solaris und darum sind beide auch so stabil auf Kosten der schnellen Weiterentwicklung oder Integration von Features.

 

[Rach78]

Da gab es in OpenZFS ein Update das nicht rückwärtskompatibel war und einen Pool move mit Illumos ZFS oder älterem OpenZFS verhindern kann. Normales zfs send ist dann der Workaround.

Das heißt doch dann übersetzt aktuelles Illumos und aktuellen OpenZFS ist zueinander nicht kompatibel wenn ich einen verschlüsseltes Dataset habe.
Für mich ist nur aktuelles Illumos und aktuellens OpenZFS relevant. Alles andere nicht.
Also ich übersätze das jetzt so dass ich dazwischen wenn ich verschlüsselung einsetze nicht kompatibel bin.

Wird diese Inkompatbilität denn erkannt beim Import oder kann man sich da einfach die Daten zerschießen?

Prinzipiell richtig, dennoch gab es in den letzten Jahren mehrfach Fälle von Datenverlust in OpenZFS durch neuere Features die in Illumos ZFS keine Auswirkung hatten - weil es das auslösende Feature nicht gab oder weil das Problem nur mit einer bestimten Kombination OpenZFS Release auf einem der vielen Linux Distributionen auftrat. OpenZFS gleicht da mehr einem Zoo mit den vielen Distributionen, jede mit einem anderen ZFS Stand und niemand weiss, ist dieses oder jenes das Zuverlässigere, hilft ein Update oder nicht.

Diese Entwicklung untergräbt dann aber irgendwie so den Sinn wieso viele ZFS einsetzen.

Beitrag automatisch zusammengeführt: Vor 57 Minuten

Normales zfs send ist dann der Workaround.

Wenn ich aber nur einen Pool habe heißt es ich muss 2mal zfs send machen, weil ich dann einen zwischenschritt über ein nicht verschlüsseltes Dataset machen muss wenn ich am Ende wieder einen verschlüsselten dataset haben will?

 

[gea]

Das heißt doch dann übersetzt aktuelles Illumos und aktuellen OpenZFS ist zueinander nicht kompatibel wenn ich einen verschlüsseltes Dataset habe.
Für mich ist nur aktuelles Illumos und aktuellens OpenZFS relevant. Alles andere nicht.
Also ich übersätze das jetzt so dass ich dazwischen wenn ich verschlüsselung einsetze nicht kompatibel bin.

Ist allerdings kein üblicher Fall, dass man einen Pool wechselseitig mit verschiedenen Betriebssystemen importieren will. In dem Fall muss man dafür sorgen, dass kein Feature verwendet wird, dass nicht auf allen Systemen geht.

Wird diese Inkompatbilität denn erkannt beim Import oder kann man sich da einfach die Daten zerschießen?

habs nie probiert, ist dann aber wohl wie mit allen Features, import nicht möglich.

Diese Entwicklung untergräbt dann aber irgendwie so den Sinn wieso viele ZFS einsetzen.

wieso. Auf einen defekten ZFS Pool kommen bei gleicher Nutzerzahl sicher ein mehrfaches an defekten ext4/ntfs oder ReFS Pools. Ausserdem hat niemand behauptet, dass man mit ZFS kein Backup haben sollte.

Wenn ich aber nur einen Pool habe heißt es ich muss 2mal zfs send machen, weil ich dann einen zwischenschritt über ein nicht verschlüsseltes Dataset machen muss wenn ich am Ende wieder einen verschlüsselten dataset haben will?

nein, bis auf den Sonderfall raw send, macht zfs send immer einen unverschlüsselten Datenstrom auch wenn source verschlüsselt war.