Systemadministratoren geraten selten in Ekstase, wenn sie über ein Dateisystem sprechen. Grosse Ausnahme ist Suns ZFS, das seit rund einem Jahr auf dem Markt ist. Denn ZFS ist mehr als ein gewöhnliches Dateisystem, nicht nur, weil es irrwitzige 16 Exabytes an Speicher adressieren kann.
Dass Sun mit ZFS ein grosser Wurf gelungen ist, beweist nicht nur das Interesse Apples an einer Integration von ZFS in MacOS X, sondern auch, dass der frei verfügbare Quellcode die strengen Qualitätsrichtlinien der Entwickler von DragonflyBSD erfüllt und diese bereits seit einigen Monaten ZFS in ihr BSD integrieren. Aber was macht ZFS so besonders?
Herausstechendes Merkmal ist sicher, wie bereits erwähnt, der verfügbare Adressraum von 128 Bit, mit dem ZFS eine nahezu unbegrenzte Speicherkapazität von 16 Exabytes (10¹⁸ Bytes) bietet. Dies ist deutlich mehr, als heutige Dateisysteme wie Silicon Graphics’ XFS mit einem Adressraum von 64 Bit ansprechen können (9 Exabytes). Ein weiteres aussergewöhnliches Merkmal von ZFS ist das integrierte Pooling von Laufwerken, das an einen Volume Manager erinnert.
Klassischerweise unterscheidet man zwischen dem Volume Manager, welcher logische Devices zur Verfügung stellt, und dem eigentlichen Dateisystem, welches auf diese aufsetzt. ZFS macht diese Unterscheidung nicht mehr. Es arbeitet nicht mehr mit den einzelnen physikalischen Platten beziehungsweise Devices, sondern mit Pools von Platten – es hat in gewissem Sinne eine Art Volume Manager integriert, auch wenn dieser Begriff nicht ganz zutreffen mag. Denn die «Volume»-Schicht ist sehr eng mit der «Dateisystem»-Schicht verknüpft und beide greifen auf Metadaten der jeweils anderen Schicht zu. So weiss beispielsweise der Pool, welche Blöcke im darüberliegenden Dateisystem belegt sind, und hat so die Möglichkeit, seine Operationen wie Mirroring nur auf belegte Blöcke zu beschränken, um so einen sehr grossen Geschwindigkeitsvorteil gegenüber klassischen Systemen zu haben, welche immer mit der gesamten Platte arbeiten – egal wie voll diese wirklich ist.
Ein sogenannter Storage Pool von ZFS besteht aus einer Menge von Platten, die je nach Bedarf als Stripe, als Mirror oder als RAID-Z, einer speziellen Variante von RAID-5, miteinander verbunden sind. Auf so einem Storage Pool wird dann das (oder mehrere) eigentliche Dateisystem angelegt. Wird eine Festplatte im laufenden Betrieb zum Pool hinzugefügt, erhöht sich die Speicherkapazität aller darauf liegenden ZFS-Dateisysteme gleichermassen, ohne übrigens an den Dateisystemen selbst Hand anlegen zu müssen, wie das bei anderen Lösungen mit Befehlen wie «growfs» nötig ist. Zur Zeit kann ZFS allerdings noch keine Platten aus einem Pool entfernen. Zwar kann man von einem Mirror eine Hälfte abtrennen und diese dann aus dem Pool entfernen. Aber die Poolgrösse und somit die Grösse der Dateisysteme selbst kann nicht verkleinert werden. Hier ist aber in naher Zukunft einiges zu erwarten.
Ein Horror für viele Administratoren ist das unbemerkte Auftreten von Inkonsistenzen im Dateisystem, das insbesondere bei grossen Datenmengen schwierig zu entdecken ist. Doch auch bei der Wahrung der Datenintegrität bietet ZFS einige Besonderheiten, mit denen klassische Problemfälle entschärft werden. So wird jede Operation über Checksummen auf etwaige Fehler überprüft. Wenn ein Fehler gefunden wird, wird entweder über den Mirror oder über die verteilte Parität bei RAID-Z der Datensatz gelesen beziehungsweise rekonstruiert, an die lesende Applikation (Benutzerprogramm) geleitet und gleichzeitig auf dem defekten Medium korrigiert (siehe Grafik).
Weiter führt ZFS regelmässig einen «Scrub» durch, bei dem sämtliche Datenblöcke auf den Medien überprüft werden, um auch bei Leerlauf (beispielsweise in einem Data Warehouse, bei dem alte Daten nur ganz selten gelesen werden) immer konsistente Daten garantieren zu können. Die Datenblöcke selbst werden mit dem sogenannten Copy-on-Write-Mechanismus geschrieben. Das bedeutet, dass beim Ändern einer Datei die Blöcke zuerst an eine andere Position auf der Platte kopiert werden und erst im Anschluss darauf eine Schreiboperation auf die Kopie erfolgt. War der Schreibvorgang erfolgreich, wird der originale Datensatz als «nicht in Verwendung» gekennzeichnet und irgendwann überschrieben. Dieser Mechanismus bietet neben der Datenkonsistenz ohne «fsck» (File System Check), der von herkömmlichen und journalisierenden Unix-Dateisystemen bekannt ist, eine sehr einfache und billige Möglichkeit von Snapshots. Ein Snapshot ist eine Momentaufnahme des Dateisystems und bietet Anwendern kurzfristig die Möglichkeit, auf ältere Zustände von veränderten Dateien zuzugreifen. Durch Copy-on-Write wird bei jedem Schreibvorgang eine Kopie der Daten angelegt. Somit hat ZFS die Kopien für die Snapshots per se immer bereits auf der Platte liegen.
Der ZFS-Snapshot selbst macht nun nichts anderes, als diese Datensätze wieder als «belegt» zu markieren und in einem eigenen, in das eigentliche Dateisystem hineingemounteten ZFS-Dateisystem read only sichtbar zu machen. Somit kann ein Snapshot – übrigens beliebig viele – praktisch augenblicklich angelegt werden. So lassen sich auch Clones eines ZFS-Dateisystems ohne Kopiervorgänge erzeugen. Clones sind sozusagen Snapshots, die beschreibbar sind, denn beim Klonen wird einfach ein neues Dateisystem angelegt, welches anfänglich komplett auf das Original verweist. Finden nun Schreiboperationen auf dem einen oder anderen Dateisystem statt, fangen diese an zu divergieren: Neu geschriebene Datensätze werden dann in das jeweilige «lokale» (aber immer auf demselben ZFS Storage Pool befindliche) ZFS geschrieben. Identische Datensätze (etwa statische Dateien wie Libraries oder andere betriebssystemeigene Dateien) teilen sich beide und belegen somit nur einmal Plattenplatz. Weder Snapshots noch Clones von Platten sollten aber als Backup gesehen werden. Dafür bietet ZFS eigene Tools, die in etwa den von BSD stammenden Werkzeugen «dump» und «restore» respektive «ufsdump» und «ufsrestore» von Solaris entsprechen.
ZFS hält sich bei der Rechtevergabe von Dateien sehr nah an die vom Windows-Dateisystem NTFS bekannten und ursprünglich von VMS abstammenden ACLs, welche viel mächtiger sind, als die von Solaris’ UFS oder von Linux-Dateisystemen bekannten POSIX ACLs. Ein weiteres von NTFS bekanntes Feature ist die Möglichkeit, Daten gleich beim Schreiben in komprimierter Form auf Platte zu legen. Das spart nicht nur Plattenplatz, sondern ist – etwa bei sehr langsamen Platten – unter Umständen auch performancemässig von Vorteil. An der Möglichkeit, Daten zu verschlüsseln, wird dagegen noch intensiv gearbeitet. Quotas unterstützt ZFS auch, allerdings keine Directory Quotas, sondern in klassischer Unix-Manier Filesystem Quotas. Da aber auch ZFS-Dateisysteme beliebig eingehängt werden können und auch vom Platzverbrauch her immer auf demselben Storage Pool liegen, lässt sich das Problem einfach durch Erzeugen weiterer ZFS-(Unter-)Dateisysteme ohne irgendwelche Implikationen oder Einbussen lösen.
Ein ZFS-Dateisystem wird nicht wie sonst üblich in /etc/vfstab zum Mounten und in /etc/dfs/dfstab zum Exportieren über NFS eingetragen, sondern bindet und exportiert sich sozusagen von selbst. Jedes Dateisystem hat eine Reihe von Eigenschaften, in denen unter anderem NFS-Exporte, Mountpunkte, Reservations-, Setuid-, Exec- oder Read-only-Flags definiert sind. Das bedeutet, dass ein ZFS-Dateisystem seine eigenen Eigenschaften unabhängig von der Betriebssystemkonfiguration verwaltet. Das macht es auch einfach, ein ZFS-Dateisystem von einem Rechner auf einen anderen zu migrieren. Dazu exportiert man das Dateisystem einfach, hängt den Plattenpool physikalisch um und importiert das Ganze dann wieder. Sämtliche Eigenschaften gehen wie bei NFS-Exporten nicht verloren, sondern wandern mit. Als
i-Tüpfelchen ist ZFS vollständig Endian-unabhängig. Das bedeutet, dass ein ZFS-Dateisystem auch von einer Big-Endian-Maschine (Sparc) auf eine Little-Endian-Architektur (x86) ohne Einschränkung oder Änderungen verschoben werden kann.
Die Administration von ZFS ist sehr simpel gehalten und erfolgt über zwei Befehle: «zpool» zum Management des Plattenpools und «zfs» für das Dateisystem selbst.
Seit kurzem gibt es aber auch die Möglichkeit, ZFS mit Suns Webinterface Web Console zu verwalten. Über die URL https://127.0.0.1:6789/zfs kann man, sofern Web Console aktiviert ist, mit einem Browser darauf zugreifen. Es bietet einen Überblick über die vorhandenen Festplatten und Pools und erlaubt deren Verwaltung per Mausklick. Ebenso lassen sich Snapshots und Clones mit Hilfe der Maus erzeugen. Darüber hinaus ist es aber auch möglich, Zutritt für andere Benutzer zu gewährleisten und Eigenschaften wie den Fehlerstatus der Devices zu überwachen.
Da die Web Console nach jeder Konfiguration anzeigt, welchen Befehl sie ausführen wird, kann man damit auch ganz schnell den Umgang mit ZFS auf der Kommandozeilen-Ebene lernen.
Gregor Longariva (longariva@softbaer.de) ist Solaris-Administrator am Rechenzentrum der Universität Erlangen-Nürnberg und Spezialist für die Unix-Betriebssysteme Solaris, OpenBSD und Linux.
