Das Dateisystem ZFS setzt Maßstäbe. Unter Linux ist aber Vorsicht geboten, denn das Zusammenspiel klappt noch nicht immer reibungslos, es drohen Datenverluste.

Das Funktionsspektrum des Dateisystems ZFS passt zu den Anforderungen moderner Geheimdienste. Ein Schelm, wer denkt, dass NSA und GCHQ insgeheim bei Sun Microsystems die Entwicklung eines Dateisystems in Auftrag gegeben hätten, das in Bezug auf Kapazität und Features den ultimativen Wurf markiert.

Ganz gleich, ob ziviles Projekt oder getarnte Regierungsarbeit – sicher ist, dass Sun Mitte 2006 das Betriebssystem Solaris 10 freigab, zu dessen Bestandteilen eben jenes Dateisystem gehörte, das mit einer Reihe Spezialfunktionen und Superlativen aufwartet. ZFS stand dabei ursprünglich für “Zettabyte File System” und spielt auf die nutzbare Größe sowie – mit der späten alphabetischen Einordnung – auf die Endgültigkeit des Dateisystems an [1].

ZFS wurde für die Verwendung mit 128-Bit-Zeigern entworfen, was das Speichern geradezu abstrus großer Datenmengen erlauben würde. Das kommentierte der Chefentwickler von ZFS, Jeff Bonwick, einmal mit der Anmerkung, dass ZFS die quantenmechanische Grenze irdischer Datenspeicherung übersteigen würde: “Man könnte einen 128-Bit-Speicher-Pool nicht füllen, ohne die Ozeane zu verdampfen.” Damit spielte er auf die Tatsache an, dass die Gesetze der Quantenmechanik eine Mindestmenge von Energie pro Informationseinheit erzwingen, soll die Information nicht aufgrund der quantenmechanischen Unschärfe verloren gehen. Bei einem Speicherpool mit 128-Bit-Adressierung übersteige diese Energiemenge jene, die zum Verdampfen aller irdischen Ozeane nötig wäre.

So unterstützen denn auch alle existierenden ZFS-Implementationen nur 64-Bit-Zeiger, nicht zuletzt aufgrund der entsprechender Restriktionen der Programmiersprache C hinsichtlich von Datentypen. Doch auch ungeachtet dieser “Beschränkung” kann ZFS noch mit beeindruckenden Rahmenwerten glänzen, wie einer maximalen Dateigröße von 16 Exbibyte (rund 17 Millionen TByte) oder bis 281 Billionen möglichen Dateien pro Dateisystem.

Daneben weist ZFS eine Reihe innovativer Eigenschaften auf. Als Copy-on-Write-Dateisystem überschreibt es geänderte Blöcke nicht, sondern speichert diese stattdessen an einen freien Platz im Dateisystem und aktualisiert danach die entsprechenden Verweise in den Metadaten. Was zunächst wie eine Verschwendung von Speicher wirken mag, bietet einige interessante Vorteile, wie etwa die Möglichkeit, ganz einfach Snapshots anzulegen: Dazu genügt es, in den Metadaten der geänderten Dateien die Verweise auf die modifizierten Datenblöcke zu erhalten.

ZFS integriert softwarebasierte RAID-Funktionen, speziell die viel verwendeten Level 1, 5 und 6. Das erhöht durch Speichern der Daten über mehrere Festplatten hinweg die Ausfallsicherheit, ohne spezielle Hardware zu erfordern. Eine ausgefeilte Technik namens RAID-Z macht es dabei möglich, die Größe der Dateisysteme im Betrieb zu erhöhen. Zusätzlich enthält ZFS ein an den LVM (Logical Volume Manager) angelehntes Volume-Management. Damit fassen Sie mehrere Partitionen und Festplatten zu einer logischen Einheit zusammen und erzeugen so sehr große Kapazitäten.

Über Prüfsummen bietet ZFS Schutz vor Fehlern beim Übertragen der Daten. Beim Speichern eines Blocks erzeugt das Dateisystem eine Checksumme, die es separat speichert und beim Lesen mit den Daten vergleicht. Das stellt sicher, dass stets konsistente Daten vorliegen – selbst wenn diese eventuell nicht aktuell sind. Das gilt insbesondere für Stromausfälle oder ähnliche plötzliche Ereignisse. Zu den weiteren Funktionen gehören Deduplizierung, absichtlich duplizierte sogenannte Ditto-Blöcke, komprimierte Daten sowie sehr einfach zu bedienende Werkzeuge zum Administrieren.

Dem gegenüber stehen einige Nachteile: So benötigt das Dateisystem eine Menge RAM (echten Hardware-Speicher, keinen virtuellen). Sun empfiehlt 1 GByte pro ZFS-Dateisystem. Auf dem Smartphone oder Raspberry Pi kommt ZFS daher wohl eher nicht zum Einsatz. Allerdings gibt es seit einiger Zeit ein Projekt, das genau diese Zielsetzung hat [2]. Neben dem Speicherhunger fällt das Dateisystem auch durch hohen Leistungsbedarf unangenehm auf: ZFS-Funktionen beanspruchen mehr Rechenzeit als solche eines Ext2- oder ähnlichen Dateisystems.

ZFS unter Linux

ZFS unterliegt der “Common Development and Distribution License”, die es nicht erlaubt, binäre Pakete frei zu verteilen. Das gilt jedoch nicht für die Weitergabe von Quelltexten, sodass die Distributionen hier einen Umweg gehen: Sie laden die Quelltexte und kompilieren diese, sodass die benötigten Tools und Module für den Kernel entstehen. Die landen anschließend in einem Paket, welches der Paketmanager letztlich installiert.

Normalerweise funktioniert das ganz gut, aber wie so oft steckt der Teufel im Detail. Bevor Sie sich anhand auftauchender Fehlermeldungen auf die Suche machen, sollten Sie vor allem Folgendes prüfen: Sind die Header-Files des aktuellen Kernels installiert und auch aktuell? Stehen die essenziellen Tools zum Kompilieren bereit?

Unter Linux gibt es derzeit zwei Ansätze, um ZFS zu nutzen. Seit 2011 existiert das Projekt “ZFS on FUSE” [3], welches das Dateisystem über einen Umweg bereitstellt. Dieser Ansatz im Userspace hat mehrere Nachteile, insbesondere arbeitet er nicht besonders flott. Parallel entstanden seit Ende 2011 mit “ZFS on Linux” [4] die ersten Versuche, die benötigten Module außerhalb des Kernels zu pflegen und zu entwickeln. Seit Frühjahr 2013 steht mit der Version 0.6.1 ein erstes alltagstaugliches Release bereit. Aktuell ist die Version 0.6.2.

Diese zweite Variante steht im Mittelpunkt des Artikels. Unter Ubuntu und Arch Linux genügt es im Idealfall, die passenden Pakete zu installieren. Das Kompilieren und Installieren der Module dauert deutlich länger als eine Installation von Binärpaketen. Die Übersetzungsskripte erzeugen am Ende zusätzlich eine entsprechende Initrd, was ebenfalls Zeit benötigt.

In der Praxis

Die Tests mit den Release Candidates von ZFS on Linux dauern seit der Version 0.60 an. Die Ergebnisse fallen dabei in der Regel gut aus, genügen aber den Ansprüchen eines produktiven Einsatzes noch nicht. Insbesondere treten immer wieder zwei Probleme auf: Bei der Installation kommt es je nach Distribution und Version dazu, dass zwar Pakete für das ZFS existieren, die Installation aber mit – zunächst unverständlichen – Fehlern abbricht oder der Kernel anschließend die benötigten Module nicht findet.

Unter Ubuntu liegt das oft daran, dass der Paketmanager die Abhängigkeiten nicht korrekt aufgelöst hat. Zum Glück lässt sich das Problem leicht beheben, indem Sie die Abhängigkeiten installieren – im Wesentlichen das Paket build-essential sowie die Header-Files des verwendeten Kernels. Danach klappt das Einspielen der ZFS-Pakete in der Regel problemlos.

Bei Arch Linux und abgeleiteten Distributionen treten mitunter ähnliche Probleme auf, die Sie auf ähnliche Weise lösen. Hier gibt es allerdings des Öfteren bei Updates Probleme, wenn noch nicht alle benötigten Pakete in der aktuellen Version vorliegen und daher Updates des Kernels erfolgen. Arch Linux ist eine Distribution mit Rolling Release.

Ein zweites Problem erscheint gravierender und bleibt bisher ungelöst: Als Kernel-Modul agiert ZFS auf der untersten Ebene des Betriebssystems. Geht dort etwas schief, erweisen sich Reparaturen manchmal als unmöglich.So führte in den Tests ein experimenteller Kernel zum Absturz. Dieser wiederum brachte das ZFS-Modul derart aus dem Tritt, dass das Dateisystem in einem inkonsistenten Zustand verblieb. Ähnliches geschah in den letzten Jahren mit unterschiedlichsten Kernel-Versionen bei verschiedenen Distributionen.

In diesem Zustand gibt es nun keine Möglichkeit mehr, das Dateisystem zu reparieren. Hier macht sich das Fehlen eines Fdisk schmerzlich bemerkbar. Selbst die in diesem Fall hinzugezogenen Entwickler von ZFS on Linux waren relativ schnell am Ende ihrer Möglichkeiten.

Auch der Versuch, das Dateisystem von einem anderen System aus zu reaktivieren – etwa FreeBSD, OpenSolaris oder Ähnlichen – führte in diesen Fällen zu reproduzierbaren Abstürzen. Angesichts dieser Erfahrungen verwundert es nicht, wenn die heute weit verbreiteten NAS-Server, die ZFS verwenden, meistens auf BSD-Varianten basieren und nicht auf Linux.

Mit Forensik-Tools wie Photorec und Scalpel gelingt es in manchen Fällen, einige Dateien zu retten. Insbesondere bei größeren Dateisystemen und großen Dateien stellt dies jedoch keine adäquate Methode dar. Kommen Kompression und Deduplizierung in Spiel, fallen diese Möglichkeiten ohnehin aus.

Ab in den Pool

Entscheiden Sie sich trotz der potenziellen Probleme für einen Test des Kernel-Moduls, gilt es, im ersten Schritt einen sogenannten Pool anzulegen. Dieser fasst ein oder mehrere physikalische Datenträger zu einem virtuellen Gerät (vdev) zusammen. Dabei abstrahiert ZFS von den realen Geräten und stellt die gewünschten RAID-Features bereit.

Virtuelle Geräte dürfen aus Block Devices, Dateien oder RAID-Verbünden bestehen. Ein Pool darf bei Bedarf beliebige Vdevs zusammenfassen. Auf diesem virtuellen Gerät legen Sie im zweiten Schritt die eigentlichen Dateisysteme an. Der Befehl zum Anlegen und Verwalten der Pools heißt zpool und folgt einer einfachen Syntax:

# zpool Befehl Option Argument

Ein Befehl legt dabei die grundlegenden Funktionen fest, die Details steuern Optionen. Die Tabelle “Zpool-Befehle” fasst wichtige Kommandos zusammen. Als Argument dienen abhängig von den Befehlen meistens Pools oder Gerätedateien.

Listing 1 zeigt einige Beispiele. Das Kommando aus Zeile 1 erzeugt einen Pool (zfs-tst) aus nur einem Gerät; der Befehl in Zeile 2 kombiniert zwei Devices. Mittels des Befehls add fügen Sie einem bestehenden Pool ein weiteres Gerät hinzu (Zeile 3).

# zpool create zfs-tst /dev/sda1
# zpool create zfs-tst /dev/sda1 /dev/sdb3
# zpool add zfs-tst /dev/sdc
# zpool replace zfs-tst /dev/sda /dev/sdc
# zpool remove zfs-tst sda

Erweist sich ein Datenträger eines Pools als defekt, lässt er sich dank der RAID-Features durch einen anderen ersetzen (Listing 1, Zeile 4). Sofern ein Pool nicht zu stark gefüllt ist, und Sie Laufwerke daraus anderweitig einsetzen möchten, entfernen Sie diese aus dem Pool (Zeile 5).

Dateisysteme anlegen

Nach dem Einrichten des oder der Pools legen Sie die Dateisysteme an. Dies geschieht mit dem Befehl zfs. Es ist möglich, vorgesehen und sogar sinnvoll, mit mehreren Dateisystemen beziehungsweise Filesystem-Hierarchien zu arbeiten.

Mehr als bei den Standard-Dateisystemen von Linux dienen Volumina hier als logische Container und gruppieren bestimmte Bereiche. So ist es gängige Praxis, für jeden Anwender ein eigenes Dateisystem anzulegen oder andere große Bereiche – etwa /usr oder /opt – in separate Dateisysteme zu legen.

Ein Vorteil dieser Methode: Sie haben die Möglichkeit, diese Bereiche dann separat zu sichern und wiederherzustellen. Dabei dürfen Sie für jedes Dateisystem einen eigenen Mountpoint angeben, den Sie bei Bedarf verändern. Ebenso individuell passen Sie die Eigenschaften der Dateisysteme an die Anforderungen an.

ZFS beherrscht ein hierarchisches Verwalten von Dateisystemen. Das erlaubt es beispielsweise, im Zweig /usr je ein weiteres Filesystem für local/, für share/ und für share/doc/ zu erzeugen. Die Dateisysteme vererben ihre Eigenschaften an die in ihnen angelegten, sodass Sie die einheitlichen Eigenschaften nicht jedes Mal neu einzustellen brauchen. Alternativ geben Sie aber jedem Dateisystem spezielle Eigenschaften mit.

ZFS unter Linux als Root-Dateisystem zu verwenden, empfiehlt sich nur nach ausgiebigem Studium der Dokumentation [5]. An allen anderen Stellen funktioniert das Anlegen von ZFS-Dateisystemen nach folgendem Schema:

# zfs create Pool/Dateisystem

Die Syntax lehnt sich an jene von Zpool an und unterscheidet zwischen Befehlen und Optionen (siehe Tabelle “Zfs-Befehle”). So erzeugt der Befehl zfs create zfs-tst/home das Hauptverzeichnis, unter dem die Anwender nun ihre eigenen Dateisysteme erhalten:

# zfs create zfs-tst/home/User

Jedem der so angelegten Dateisysteme weisen Sie mit set Eigenschaften zu: Die erste Zeile in Listing 2 setzt beispielsweise die Eigenschaft compression. Für untergeordnete Dateisysteme ändern Sie diese nach Bedarf (zweite Zeile). Analog zu set listet get die vorhandenen Properties auf; ohne Argument zeigt es eine Liste der Eigenschaften.

# zfs set compression=gzip-6 zfs-tst/home
# zfs set compression=lzjb zfs-tst/home/User1

Das nachträgliche Ändern erlaubt es, nach dem Kopieren großer Mengen gut komprimierbarer Dokumente das Verfahren zur Kompression anzupassen. Die neuen Eigenschaften wirken sofort. Auch so grundlegende Eigenschaften wie den Mountpoint geben Sie auf diese Weise an. Da die Einhängepunkte im Dateisystem definiert sind, brauchen Sie diese nicht in /etc/fstab einzutragen.

Das System mountet ZFS-Dateisysteme automatisch, nachdem der Kernel die benötigt Module lädt und der entsprechende Service startet. Dies lässt sich für einzelne Dateisysteme bei Bedarf verhindern (Listing 3).

# zfs set mountpoint=legacy ZFS-Dateisystem

Sicherheit und Effizienz

ZFS-Dateisysteme gelten als robust, da sie für alle geschriebenen Blöcke eine Checksumme errechnen. Dieses Verfahren gewährleistet, dass das Filesystem viele Fehler sicher erkennt, wenn auch erst beim erneuten Lesen der Blöcke [6].

Diese Verfahren arbeiten unabhängig vom Software-RAID. Daher funktionieren sie auch mit nur einem Datenträger, das Dateisystem gilt als selbstheilend. Dafür startet das ZFS einen niedrig priorisierten Prozess, der alle Blöcke einzeln einliest, die Daten mit den Prüfsummen vergleicht und – soweit möglich – repariert. Im Bedarfsfall lässt sich dieser Prozess mit scrub explizit anstoßen (Listing 4, Zeile 1). Wie viel Zeit das in Anspruch nimmt, zeigt der Status an (Listing 4, Zeile 2).

# zpool scrub Pool
# zpool status
  pool: zfs-tst
  state: ONLINE
  scan: scrub in progress since Thu Jan 30 14:50:27 2014
    381M scanned out of 697M at 54,4M/s, 0h0m to go
    0 repaired, 54,61% done
config:
        NAME        STATE     READ WRITE CKSUM
        zfs-tst     ONLINE       0     0     0
          sda13     ONLINE       0     0     0
errors: No known data errors

Die Prüfsummen erlauben es darüber hinaus, Blöcke eindeutig zu identifizieren. Dies ermöglicht eine Deduplikation. ZFS verwaltet die Checksummen aller bisher geschriebenen Blöcke in einer Datenbank. Blöcke, deren Prüfsummen es kennt, schreibt es nicht nochmals auf die Datenträger, sondern setzt einen Verweis auf den bereits vorhandenen. Sie aktivieren diese Eigenschaft wie folgt:

# zfs set dedup=on ZFS-Dateisystem

Die Checksummen errechnet ZFS voreingestellt mit dem SHA5-Algorithmus. Im Prinzip wäre es hier möglich, dass zwei unterschiedliche Blöcke die gleiche Prüfsumme aufweisen – beim Deduplizieren ein fataler Fehler. Aus diesem Grund beherrscht ZFS mit der Option dedup=verify ein bitweises Vergleichen, was auf Kosten der Geschwindigkeit die Sicherheit erhöht.

Ebenfalls zusätzlich Sicherheit versprechen die “ditto blocks”. Sie bestehen aus identischen Blöcken von Daten, auf die das Dateisystem zugreift, wenn ein gelesener Block nicht mit der Checksumme übereinstimmt, weil er defekt ist. Die Eigenschaft copies definiert die Anzahl der Kopien (Listing 5).

# zfs set copies=2 zfs-tst
# zfs get copies
NAME        PROPERTY  VALUE   SOURCE
zfs-tst     copies    2       default
...

Compression und Snapshots

Das Dateisystem verfügt über eingebaute Methoden zur Kompression, die analog zu Gzip auf Blockebene funktionieren. Das Kommando compression aktiviert diese Eigenschaft:

# zfs compression=gzip-7 zfs-tst

Alternativ zur Option gzip-Rate stehen auch andere Verfahren bereit, wie lzjb, gzip, zle und lz4. Welches davon die besten Ergebnisse erzielt, hängt maßgeblich von den gespeicherten Daten ab. Die Wirksamkeit der verwendeten Algorithmen zeigt sich nach dem Speichern in der Eigenschaft compressratio.

Ein anderes wichtiges Features basiert auf dem Verfahren Copy-on-Write. Dabei löscht das System veraltete Daten auf dem Datenträger nicht, sondern deklariert lediglich deren Referenzen für ungültig. Das ermöglicht es, später auf einfache Weise einen bestimmten Zustand des Dateisystems wieder zu restaurieren: Durch das explizite Speichern der Metadaten zu einem Zeitpunkt erstellen Sie einen Snapshot.

Normalerweise legen Sie Snapshots explizit an. Das erfolgt über den gleichnamigen Befehl (Listing 6, Zeile 1). Vor dem “Klammeraffen” @ geben Sie das fragliche Dateisystem an, dahinter den Bezeichner des Snapshots. Anschließend finden Sie diesen mit dem Befehl list wieder (Zeile 2). Einen kompletten Schnappschuss stellen Sie in einem Schritt ins aktuelle Dateisystem zurück, nehmen also einen “Rollback” vor (Zeile 6).

# zfs snapshot zfs-tst@initial
# zfs list -t snapshot
NAME            USED  AVAIL  REFER  MOUNTPOINT
zfs-tst@initial    0      -   144K  -
...
# zfs rollback zfs-tst@initial

Wollen Sie zunächst wissen, was sich in dem aktuellen Dateisystem seit dem letzten Schnappschuss geändert hat, hilft Ihnen diff weiter. Es eignet sich zum Ermitteln von Unterschieden zwischen Schnappschüssen.

Legen Sie zunächst einen weiteren, aktuellen Schnappschuss an (Listing 7, Zeile 1). Dann ermitteln Sie die Unterschiede (Zeile 2). Mit M kennzeichnet ZFS veränderte Dateien oder Verzeichnisse, ein Plus-Zeichen steht für neue Dateien, ein R für umbenannte und ein Minus-Zeichen für gelöschte Files.

# zfs snapshot zfs-tst@now
# zfs diff zfs-tst@initial zfs-tst@now
...
M       /zfs-tst/
+       /zfs-tst/new

Weiterhin ermöglicht das Copy-on-Write im Prinzip, auf ältere Versionen einer Datei zuzugreifen, solange die zu ihr gehörenden Blöcke und Metadaten noch existieren. Dazu blenden Sie über snapdir=visible ein verstecktes Verzeichnis ein, welches das Dateisystem normalerweise grundsätzlich nicht anzeigt.

Anschließend finden Sie in der ersten Ebene des Dateisystems das spezielle Verzeichnis .zfs. Darin finden sich zwei weitere Ordner namens shares/ und snapshot/. Ersterer enthält die freigegebenen Verzeichnisse, Letzterer die bisher angefertigten Schnappschüsse. Daraus stellen Sie versehentlich gelöschte oder veränderte Dateien wieder her.

Fazit

Die überragenden Eigenschaften von ZFS verleiten leicht dazu, es unter Linux in Betrieb zu nehmen. Aber noch droht der Verlust von Daten, was gegen einen Einsatz auf einem Produktivsystem spricht. Die derzeitigen Ansätze erlauben es aber, sich schon jetzt mit den Fähigkeiten des Dateisystems vertraut zu machen. So sind Sie gewappnet, sobald ZFS reibungslos unter Linux funktioniert – oder die freien Alternativen ähnliche Fähigkeiten mitbringen.