Der OpenSolaris fork Openindiana und ZFS, das beste Filesystem wo gibt von ganze Welt.

Das ZFS derzeit das geilste Filesystem überhaupt ist, muss ich ja keinem mehr sagen. Aber ich möchte 😀 Boar ist das GEIL!

Zurück zum Thema und damit zu ein paar technischen Eckdaten

Wortlänge 128 Bit (wer noch die letzten Zahlen in Sachen IPv6 im Kopf hat, der hat eine Ahnung von 128Bit Zahlen :D)
Volumemanager Integriert (im groben weiss das Dateisystem was die Platten machen und umgekehrt)
Ausfallsicherheit RAID 1, RAID-Z1 (1 Parity-Bit, ~RAID 5), RAID-Z2 (2 Parity-Bits, ~RAID 6) und RAID-Z3 (3 Parity-Bits) integriert
maximale Größe des Dateisystems 16 exbi Byte (= 16 × 260 Byte)
maximale Größe jedes Pools 3 × 1023 pebi Byte (ca. 2 × 1038 Byte)
maximale Anzahl an Dateien in einem Verzeichnis 248
maximale Anzahl an Geräten im Pool 264
maximale Anzahl an Dateisystemen im Pool 264
maximale Anzahl an Pools im System 264

Wenn man nun mal von den irren Maximalwerten absieht, was genau ist denn jetzt so neu? Tja, grob betrachtet kaum etwas… Snapshots gibt es schon, vergrößerbare Dateisysteme auch, Verschlüsselung gibt es schon lange, Raid ist ebenso ein alter Hut, Snapshots sind alles andere als neu usw. usw.. Das aber alles zusammen kombiniert wird, das ist hier das Neue 😀

Die Kombi? Japp… Als kleines Beispiel: Normalerweise ist es bei einem Raidverbund so, dass sich der Raidcontroller bzw. ein paar Softwarestücke (beim Softwareraid) um die Platten kümmen. Der eigentliche Raidverbund hat keine Ahnung Ob Daten auf den Platten liegen. Nicht einmal ob es überhaupt ein Dateisystem oder gar eine Partitionstabelle gibt ist ihm bewusst. Soll jetzt z.B.: alle Platte durchgesync (resilvered) werden, muss das Byte für Byte passieren, egal wieviel von den Platten nun wirklich belegt ist. Ob nun 2TB oder halt nur 1kb auf dem Raidverbund liegt. Das Resilvering dauert die gleiche Zeit (ewig). Das wäre beim ZFS anders, denn ZFS weiss genau welche Daten wo liegen. Somit müssen nur die Teile mit Daten syncronisiert werden.

ZFS unterstützt einfaches Striping, einen Mirror, Raid5 (raidz), Raid6(raidz2) und natürlich Spares. In Sachen Datensicherheit ist das aber noch lange nicht alles…. ZFS verbessert selbst die Datensicherheit bei einzelnen Festplatten. Dafür gibt es Ditto Blöcke…. Wird dieses aktiviert, werden für jeden logischen Block bis zu drei physische Blöcke auf der Platte verteilt. Das verschwendet zwar echt Platz auf der Platte, erhöht dafür die Chance selbst bei einer def. Platte Daten rekonstruieren zu können extrem.

Macht ein Festplattenkontroller nicht was er soll oder ein Kabel hat einen def. kann es zu extrem dummen Fehlern kommen oder gar zu Silent Data Corruption (leisem/unbemerktem Datenverlusst). Das bedeutet: Die eigentlichen Daten auf der Festplatte werden stellenweise unbrauchbar. Das merkt man aber erst wenn man versucht auf diese Daten zuzugreifen. Selbst ein Dateisystemscan kann fehlerfrei durchlaufen, denn noch sind die Daten im Eimer. ZFS bietet hier nicht nur die einfache Möglichkeit von Blöcken Checksummen zu bilden, nein es integriert Hash Trees. So können Checksummen in einer Baumstrucktur erstellt werden und es können z.B. sogar versehentlich überschriebene Blöcke erkannt werden. Diese Probleme löst ZFS dann, wenn möglich schon automatisch. Sind Daten gespiegelt kann so direkt festgestellt werden, auf welcher Platte def. Daten liegen. Das ZFS unter anderem dieses kann gilt es als selbstheilendes Dateisystem.

Nach offizieller Aussage soll man ein ZFS Dateisystem nicht kaputt bekommen (es sei denn man schlägt mit dem Hammer drauf :-P). Dateisysteme wie NTFS, ext3, xfs usw…. benutzten journaling um zu erledigende Aufgaben bzw. Aufgaben die noch anstehen zu protokollieren. ZFS arbeitet da eher wie moderne Datenbanksysteme. Es nutzt das ZFS Intent Log… Dort wird genau aufgeführt was ZFS nun gerade vor hat und im Falle eine Stromausfalles oder ähnlich kann ZFS dort ganz genau nachvollziehen was passieren sollte. Für alle Fälle gibt es natürlich die Möglichkeit sein Dateisystem zu überprüfen. Dieses nennt sich unter ZFS scrubbing (total lustiger aber auch passender Begriff, oder?).

Ganz cool ist die Möglichkeit immer und zu jedem Moment Snapshots vom aktuellen Dateisystem anzufertigen. Somit lässt sich immer der aktuelle Zustand einfrieren. Da es zusammen mit Copy on Write läuft, werden im groben die aktuellen Daten einfach so gelassen wie sie sind und erst bei einer Veränderung wird diese einfach an eine andere Stelle geschrieben. Es passiert also nicht das Daten doppelt und dreifach durch einen Snapshot im Pool liegen 🙂

Ich kann nun wenn ich Bock habe einfach auf einen der Snapshots zurück springen, ich kann Snapshots von Hand oder auch per Cronjob erstellen… Von mir aus alle 10 oder 15 Minuten 😀 Ich kann einen Clone aus einem Snapshot erstellen, welcher dann wieder veränderbar ist. Ich kann auch per SSH einen Snapshot auf eine andere Maschine irgendwo auf der Erde schieben und somit meinen ZFS Pool sichern/synconisieren… Dort könnte ich vorher zusätzlich noch einen Snapshot erstellen usw. usw. usw…..

Dieses ist nun nur ein Bruchteil von dem was mit ZFS möglich ist, man sieht jetzt schon schnell was mit ZFS alles möglich ist!