Original-URL des Artikels: https://www.golem.de/news/zfs-ausprobiert-ein-dateisystem-fuers-rechenzentrum-im-privaten-einsatz-1710-129252.html    Veröffentlicht: 11.10.2017 12:05    Kurz-URL: https://glm.io/129252

ZFS ausprobiert

Ein Dateisystem fürs Rechenzentrum im privaten Einsatz

Unter Linux ist EXT4 Standard, moderne Features fehlen dem Dateisystem allerdings. Mit ZFS existiert eine Alternative. Die zwingt den Nutzer aber zur Umgewöhnung, wie wir herausgefunden haben.

Apple bringt mit High Sierra das bereits in iOS integrierte APFS (Dateisystem) und Microsoft arbeitet an ReFS. Da kommt man sich mit EXT4 als Standard-Dateisystem unter Linux schon recht altmodisch vor! Doch mit ZFS existiert auch eine Alternative mit modernen Features. Ich habe sie ausprobiert.

Für den ein oder anderen stellt sich vermutlich die Frage, warum ein neues Dateisystem unter Linux überhaupt nötig ist. Die simple Antwort lautet: Ist es nicht, EXT4 ist weit etabliert, stabil und hat vor einiger Zeit das letzte Update erhalten, das es für die kommende Hardware-Generation fit machen soll. Der Vorteil eines neuen Dateisystems liegt vor allem für Desktops und Workstations bei neuen Funktionen, die die Arbeitsumgebung maßgeblich verbessern können.

Was ZFS ist

ZFS ist die Kurzform für Zettabyte File System. Während Dateisysteme unter Linux in der Regel als formatierte Partition gesehen werden, die in die FSTAB eingebunden werden, ist ZFS grundlegend anders: Optimalerweise gibt man ihm eine oder mehrere Festplatten und kann danach sogenannte Datasets erstellen. Das sind letztendlich nichts anderes als Partitionen einer Festplatte - nur besser. ZFS übernimmt dabei nicht nur die Rolle eines traditionellen Dateisystems, vielmehr ist es Raid-Controller, Volumen-Manager und Dateisystem in einem.

Neue Abkürzungen werden eingeführt

Während es sich bei EXT4 nur um ein Dateisystem handelt, ist ZFS deutlich komplexer aufgebaut. Ein sogenannter Speicher-Pool besteht aus einem oder mehreren VDEVs. Diese sind letztendlich nichts anderes als einzelne Partitionen, Festplatten oder eine Art Raid-Verbund - der als RaidZ, RaidZ2 oder RaidZ3 bezeichnet wird. RaidZ kann einen Festplatten-Ausfall tolerieren, RaidZ2 zwei -Ausfälle und RaidZ3 drei. Zusätzlich gibt es die Option, zwei oder mehrere Partitionen/Festplatten zu spiegeln.

Neben dieser Hauptgruppe, auf der alle Daten des Pools gespeichert werden, gibt es noch zwei weitere Bestandteile: das ZFS Intent Log (kurz: ZIL) und den Cache. Der Cache bleibt im Arbeitsspeicher und folgt einem adaptiven Austauschalgorithmus (Adaptive Replacement Cache, ARC), um häufig genutzte Daten schnell aufrufen zu können. Wenn Daten im Arbeitsspeicher weichen müssen, werden sie auf einen optionalen, eigenständigen Cache geschrieben: den L2ARC (Level 2 ARC).

Das ZFS Intent Log ist zu komplex, um hier darauf einzugehen. Die genaue Funktionsweise wird auf einer eigenen Webseite erläutert.

Datenintegrität ist am wichtigsten

Hätten die Sturmtruppen des Imperiums ZFS zum Datenabgleich eingesetzt, wäre ihnen wohl einiges erspart geblieben. Datenintegrität steht bei ZFS an erster Stelle. Die verschiedenen Raid-Level versprechen einen Schutz der Daten bei dem leider nicht seltenen Ausfall einer Festplatte, während ZFS intern jede gelesene Datei mit ihrer beim Schreiben generierten Checksumme abgleicht und im Falle eines Fehlers, falls möglich, repariert. Fehlerhafte Urlaubsbilder, Videos oder auch Textdateien gehören der Vergangenheit an.

Die Integritätsprüfung ist einer der Hauptgründe dafür, dass die Entwickler von ZFS vorsehen, fehlerkorrigierenden Arbeitsspeicher (ECC, registered ECC) einzusetzen. Dieser ist sinnvoll in Rechenzentren oder bei Backups, beim Desktop-Einsatz muss man aber nicht explizit auf den fehlerkorrigierenden Arbeitsspeicher achten. Auf meinem Notebook beispielsweise läuft eine Installation von ArchLinux unter ZFS, ohne in den letzten sechs Monaten einen einzigen Fehler gezeigt zu haben. Wer viel Wert auf die Verfügbarkeit seiner Backups legt, sollte in Erwägung ziehen, ein NAS mit fehlerkorrigierendem Arbeitsspeicher aufzubauen.

Hilfe, wo ist mein Arbeitsspeicher hin?

Bei dem Einsatz von ZFS passiert es sehr häufig, dass der verfügbare Arbeitsspeicher kleiner wird. Der ARC belegt bis zu zwei Drittel des vorhandenen Arbeitsspeichers - ungenutzter Arbeitsspeicher ist schließlich Verschwendung. Theoretisch ist ZFS so ausgelegt, dass die Größe sich je nach laufenden Prozessen und benötigtem Arbeitsspeicher anpasst. Bei mir funktioniert das oftmals nicht, wenn plötzlich ein großer Teil des Arbeitsspeichers auf einmal alloziert wird.

Um dem Problem zu entgehen, habe ich die Größe des ARC in den Bootparametern limitiert. Die genaue Vorgehensweise wird im Gentoo-Wiki beschrieben. Eine Limitierung ist nur notwendig, wenn dem System weniger als 16 GByte Arbeitsspeicher zur Verfügung stehen. Auf meiner Workstation mit 64 GByte Arbeitsspeicher musste ich den ARC nicht limitieren.

Arbeitsspeicher-Einsatz spart Festplattenspeicher

ZFS unterstützt von Haus aus eine automatische Komprimierung geschriebener Daten - ohne dass Benutzer etwas davon mitbekommen. Der schnelle lz4-Algorithmus bremst selbst eine NVME-SSD nicht aus, und das bei akzeptabler CPU-Auslastung. Doch nicht nur durch Komprimierung spart ZFS wertvollen Platz auf der Festplatte. Wer RAM zu verschenken hat, kann das Deduplication-Feature aktivieren. Wenn ZFS genug Arbeitsspeicher für sich beschlagnahmt hat, werden keine Daten mehr doppelt auf die Festplatte geschrieben.

ZFS-Installation mit Hürden

Jede aktuelle Distribution unterstützt zwar ZFS, das System auf einem ZFS-Pool zu installieren, gestaltet sich aber mal mehr, mal weniger schwierig. Grund hierfür ist die Geschichte von ZFS. Erstmals veröffentlicht wurde es von Sun Microsystems im Jahr 2006 unter der CDDL, einer Open-Source-Lizenz, die aber inkompatibel zur GPL des Linux-Kernels ist.

Als Oracle Sun Microsystems 2009/10 übernahm, wurde ZFS von Oracle proprietär weiterentwickelt. Der derzeitige Weg zur Nutzung von ZFS ist das OpenZFS-Projekt. Es geht auf die letzte veröffentlichte Version des ZFS-Quellcodes zurück und hat Einzug in Repositorys vieler Distributionen gefunden. Die Lizenz-Problematik wird mit dem Einsatz von Dynamischen Kernel-Modulen (dkms) gezielt umgangen. Doch genau dieser Umweg macht die Installation auf einem ZFS-Pool komplexer als das gewohnte Weiterklicken mit anderen Dateisystemen.

Am anwenderfreundlichsten läuft der Prozess ironischerweise mit Archlinux. Nachdem ein Installationsimage mit ZFS erstellt wurde, wird das System auch mit ZFS installiert. Eine Anleitung dazu findet sich im Archlinux-Wiki.

Von Solaris zu Linux

ZFSonLinux, die OpenZFS- Implementierung unter Linux, besteht aus zwei Teilen: dem eigentlichen ZFS-Modul und dem Solaris Porting Layer, kurz: SPL. Dieser ermöglicht es, Code, der für den Solaris-Kernel entwickelt wurde, unter dem Linux-Kernel auszuführen. Für ZFSonLinux bedeutet das konkret: Es muss nichts portiert werden - die Änderungen am Code, um ZFS unter Linux lauffähig zu bekommen, sind minimal. Die Entwicklung geht somit schneller voran und es schleichen sich keine Fehler im Portierungsprozess ein.

ZFS-Pool erstellen

Vor der Erstellung eines ZFS-Pools müssen sich Nutzer Gedanken über den Aufbau machen. Ob es ein RaidZ wird, eine Spiegelung oder eine Art Raid-0 , bleibt ihnen überlassen. In meinem Notebook ist Platz für eine einzige NVME-SSD, ein Raid-Level ist daher nicht möglich. Da ich sowohl eine EFI Boot- Partition als auch einen kleinen SWAP benötige, formatiere ich zuerst die SSD in 3 Partitionen: eine für ZFS, eine für die EFI-Systempartition und eine für die Auslagerungspartition.

Um den ZFS-Pool zu erstellen, nutze ich die Kommandozeilen-Anwendung zpool. Mit folgendem Befehl erzeuge ich meinen Pool, auf dem ich später das System installiere:
zpool create zroot /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_500GB_****-part2 zpool status verrät mir, ob alles geklappt hat!

Sofern alles fehlerfrei verlaufen ist, erstelle ich mir Datasets für / und /home: zfs create -o mountpoint=none,compression=lz4 zroot/ROOT zfs create -o mountpoint=/ zroot/ROOT/arch zfs create -o mountpoint=none,compression=lz4 zroot/data zfs create -o mountpoint=/home zroot/data/home

Danach kann die Installation für die gewünschte Distribution beginnen!



Als Backup dient ein Schnappschuss

Nicht nur Arbeiten am Dateisystem können zu einem korrupten oder nicht mehr lauffähigen System führen, oftmals sind auch Updates oder schlicht Benutzerfehler schuld. Ein Backup ist daher immer eine gute Idee. Was bei EXT4 aufwendig war, ist mit ZFS sehr einfach zu lösen. Anstatt alle Dateien zu kopieren, kommt ein Schnappschuss zum Einsatz: zfs snapshot zroot/ROOT/arch@testsnapshot01

Der soeben erstellte Schnappschuss testsnapshot01 nimmt nur so viel Platz weg, wie die Dateien, die nach ihm geschrieben oder verändert werden. ZFS folgt dem Copy-on-Write-Prinzip (kurz COW). Dies ermöglicht nicht nur sehr schnelle und platzsparende Schnappschüsse von Datasets, sondern stellt auch sicher, dass im Falle eines Stromausfalls immer eine vollständige Version der Datei verfügbar ist.

Nachdem unser Schnappschuss erstellt ist und die Datei /foo geändert wurde, kopiert ZFS sie und schreibt erst dann die Änderungen. Der Schnappschuss nimmt dann den Speicherplatz der Änderung in Anspruch - oftmals sind dies nur einige Megabyte. Als kleines Beispiel: Die vergangenen anderthalb Monate an täglichen Snapshots belaufen sich auf etwa 14 GByte.

RSYNC wird obsolet

Bisher habe ich meine Backups immer mit rsync gemacht - oftmals ein langer Prozess, da alle Daten durchlaufen werden müssen. ZFS führt zwei unvergleichbar nützliche Funktionen ein: zfs send und zfs receive. Sie ermöglichen das Empfangen und Senden von Snapshots. Was so selbstverständlich klingt, macht in der Praxis einen großen Unterschied. Um unseren testsnapshot01 Schnappschuss über SSH an ein anderes Dataset zu senden, das auf einem anderen ZPOOL liegt, benötige ich eine Zeile:

zfs send zroot/ROOT/arch@testsnapshot01 | \ ssh flora.local zfs receive zbackup/backup/lola

Je nach Größe dauert dieser Vorgang einige Zeit. Wenn man sich in einem lokalen Netzwerk befindet, muss man nicht SSH nutzen, sondern kann auf netcat oder eine Alternative dafür zurückgreifen.

Jetzt kann ich einen neuen Schnappschuss anlegen: tesnsnapshot02. Um auch von diesem nun ein Backup zu machen, muss ich jetzt nicht mehr den kompletten Snapshot senden, sondern nur die Änderungen zum vorherigen. Dies geht mit:

zfs send -i zroot/ROOT/arch@testsnapshot01 zroot/ROOT/arch@testsnapshot02 | \ ssh flora.local zfs receive zbackup/backup/lola

Warum ZFS statt BTRFS?

BTRFS (gesprochen ButterFS) wird alle Funktionen von ZFS bieten mit dem großen Vorteil, lizenzkompatibel mit dem Linux-Kernel zu sein. Warum also nicht auf BTRFS setzen? Wenn man sich einmal den Projektstatus anschaut, wird klar, dass es noch eine Weile dauern wird, bis BTRFS konkurrenzfähig ist. Mostly OK oder gar Unstable vertraue ich meine Daten nicht an. Zudem hat Redhat die Unterstützung von BTRFS aufgegeben, was voraussichtlich einige Folgen für das Projekt haben wird.

Sowohl im Desktop als auch im mobilen Einsatz ist ZFS den Standard-Dateisystemen weit überlegen. Für mich persönlich sind vor allem die schnellen und einfachen Backups basierend auf Snapshots das Hauptkriterium zum Einsatz von ZFS.  (mrl)


Verwandte Artikel:
Betriebssysteme: Oracle überrascht mit Solaris 11.4 Beta   
(02.02.2018, https://glm.io/132545 )
Statt Docker und Kubernetes: Facebook braucht Tupperware für seine Container   
(24.10.2017, https://glm.io/130782 )
Librem 5: Purism-Smartphone bekommt Smartcard für Verschlüsselung   
(09.03.2018, https://glm.io/133248 )
Retrofit Kit: Alte MacOS-Versionen für APFS fit machen   
(22.02.2018, https://glm.io/132913 )
Ransomware: Krankenhaus zahlt 60.000 US-Dollar trotz Backups   
(17.01.2018, https://glm.io/132206 )

© 1997–2019 Golem.de, https://www.golem.de/