Frage zu ZFS Daten Integrität + ISCSI

[Grinchy]

Hallo zusammen,

ich plane derzeit meinen FreeNAS Setup und wollte einmal nachfragen, ob die automatische Korrektur (bei Checksummenabweichungen) von ZFS auch in Kombination mit ISCSI funktioniert?

Wenn ich das richtig verstanden habe erstellt ein ISCSI Lun ja einen großen Container der dann unter Windows nochmal formatiert wird (NTFS oder ReFS).
Nur hat ZFS dann ja gar keine Einsicht auf die Daten die auf dem ISCSI Volumen gespeichert sind, sondern sieht nur eine große Datei, oder?

Ist hier eine automatische Reparatur trotzdem möglich? Wenn die Reparatur funktioniert, kann ZFS dann einfach nur die defekten Sektoren austauschen, oder müsste es das gesamte Lun neu schreiben?

Mein derzeit angestrebter Setup wären 5x6TB im Raid Z1. Wobei ich langfristig auch auf Raid Z2 umsteigen möchte, da Z1 bei einem Ausfall ja keine Integrität mehr bereitstellen könnte. Mir ginge es hier vor allem um den Schutz vor Silent Data Corruption und URE. Ein Backup wäre sowieso extra vorhanden.

Liebe Grüße

 

[MrToddsFriends]

Ist hier eine automatische Reparatur trotzdem möglich? Wenn die Reparatur funktioniert, kann ZFS dann einfach nur die defekten Sektoren austauschen, oder müsste es das gesamte Lun neu schreiben?

Die ZFS-Features Checksumming und Fehlerkorrektur sind immer block-, nicht datei-basiert, sodass die Frage iSCSI oder nicht keinen Unterschied machen dürfte.
http://doc.freenas.org/11/zfsprimer.html
https://en.wikipedia.org/wiki/ZFS#Summary_of_key_differentiating_features

Wobei ich langfristig auch auf Raid Z2 umsteigen möchte, da Z1 bei einem Ausfall ja keine Integrität mehr bereitstellen könnte. Mir ginge es hier vor allem um den Schutz vor Silent Data Corruption und URE. Ein Backup wäre sowieso extra vorhanden.

Einen Umstieg von Z1 auf Z2 würde ich wenn möglich wegen des damit verbundenen Aufwands vermeiden (Neuerstellung des Pool und Zurückspielen der Daten aus Backup) und gleich mit Z2 beginnen.

 

[Grinchy]

Vielen dank für die schnelle Antwort!

Hat der Einsatz von ISCSI seitens ZFS denn irgendwelche Nachteile im Vergleich zu SMB?

Wenn ich das richtig verstanden habe, funktioniert ZFS zwar blockbasiert, merkt sich aber trotzdem die Datei die zu dem Block gehört. Hierdurch kann zB. bei einem Fehler beim Wiederaufbau des Raids (zB. URE) nur die Defekte Datei ausgelassen, und der Aufbau vorgesetzt werden ohne den kompletten Raid zu zerstören. Stimmt das soweit?

Nur grade dies wäre bei einem ISCSI ja dann nicht möglich, weil es ja nur eine große Datei (das komplette Lun) gibt?


Sorry für die vielen Fragen, ich versuche nur derzeit abzuwiegen ob ich SMB oder ISCSI nutzen soll.
Wobei mir bislang ISCSI eigentlich Sympathischer war, da Windows mit ISCSI Laufwerken etwas angenehmer zu bedienen ist (zB. auch Bitlocker).


Das hat jetzt zwar nichts direkt mit dem Thema zu tun, aber wie werden die Festplatten den "verbunden" wenn man verschiedene Festplatten ohne Raid in einen ZFS Pool zusammenfügt? Ist das dann einfach nur ein Raid 0 oder ein JBOD? Könnte man hier ein Laufwerk entfernen, oder wären dann alle Daten weg?

 

[MrToddsFriends]

Hat der Einsatz von ISCSI seitens ZFS denn irgendwelche Nachteile im Vergleich zu SMB? [...]

Ich kenne mich mit iSCSI nicht aus, Deine diesbezüglichen Fragen kann hoffentlich jemand anderes beantworten.

Ein Nachteil von iSCSI taucht hier im Forum allerdings immer wieder auf: Man sollte den zugrunde liegenden Pool nicht zu mehr als 50% füllen. Beschrieben ganz unten ("caveats") im ZFS Primer.

Edit: Zusammen mit dem vielfach hier im Forum zu lesenden Tipp, aus Performancegründen bei iSCSI Mirrors (und nicht RaidZ1/RaidZ2/RaidZ3 VDevs) einzusetzen, landet man bei einer Nutzbarkeit von bestenfalls 25% des rohen Plattenplatzes.

Das hat jetzt zwar nichts direkt mit dem Thema zu tun, aber wie werden die Festplatten den "verbunden" wenn man verschiedene Festplatten ohne Raid in einen ZFS Pool zusammenfügt? Ist das dann einfach nur ein Raid 0 oder ein JBOD? Könnte man hier ein Laufwerk entfernen, oder wären dann alle Daten weg?

Ein ZFS Volume besteht entweder aus einem einzelnen Vdev (virtual device) oder ist ein Stripe über mehrere VDevs. In dem von Dir angesprochenen Fall besteht jedes einzelne Vdev aus genau einer Platte und hat demnach keine Redundanz. Ein daraus gebildetes Volume ist demnach ein Stripe über die einzelnen Platten. Der Ausfall einer einzelnen Platte in so einem Volume zieht den Verlust der Daten des gesamten Volumes nach sich.

 

[X11SAE]

Wenn ich das richtig verstanden habe, funktioniert ZFS zwar blockbasiert, merkt sich aber trotzdem die Datei die zu dem Block gehört. Hierdurch kann zB. bei einem Fehler beim Wiederaufbau des Raids (zB. URE) nur die Defekte Datei ausgelassen, und der Aufbau vorgesetzt werden ohne den kompletten Raid zu zerstören. Stimmt das soweit?

Nur grade dies wäre bei einem ISCSI ja dann nicht möglich, weil es ja nur eine große Datei (das komplette Lun) gibt?

Ich bin nicht sicher, ob ich die Funktion von ZFS hier korrekt verstanden habe. Wenn Deine Aussage oben korrekt wäre, dann müsste ZFS ja die Dateien auch öffnen können um zu überprüfen, ob sie defekt sind. Das kann aber nicht wirklich sein, denn z.B. verschlüsselte Archive oder Windows Installer Files können von FreeBSD nicht geöffnet werden und würden demnach als defekt eingestuft werden.
Wenn sich der Defekt auf einen Checksummenfehler beschränkt, dann wird ZFS versuchen die Datei zu reparieren. Das funktioniert auch bei iSCSI.

 

[mkninc]

Bei iSCSI wird im Normalfall ein ZVOL angelegt(keine Datei) und dem System als Blockdevice zur Verfügung gestellt. Weiß jetzt nicht genau wie es sich verhält, aber im Falle eines defektes, und wenn keine weitere Redundanz vorhanden ist, wird das vermutlich direkt als IO Fehler "nach oben" gereicht. Dort ist dann ja nochmal ein Dateisystem, z.B. NTFS, draufgesetzt. Das muss halt mit dem IO Fehler klar kommen. Das verhält sich dann wie ein defekter Sektor einer normalen Festplatte. Sprich es hängt vom Dateisystem ab, was noch lesbar ist.