ZFS

ZFS verbindet zwei Aufgaben, die sonst getrennt sind: das Dateisystem und die Verwaltung der Datenträger (Volume-Management). Weil ZFS den gesamten Weg vom logischen Block bis zur physischen Platte kennt, kann es durchgehend für Integrität und Konsistenz sorgen, statt einer darunterliegenden RAID- oder LVM-Schicht zu vertrauen.

Statt einzelne Partitionen zu formatieren, fasst ZFS Datenträger zu einem Pool (zpool) zusammen, aus dem sich Dateisysteme (Datasets) und Block-Geräte (zvols) bedienen. Der Speicher wird dynamisch zugeteilt; feste Partitionsgrenzen entfallen.

Kern ist das Copy-on-Write-Prinzip: ZFS überschreibt nie einen bestehenden Block, sondern schreibt geänderte Daten an eine neue Stelle und hängt erst danach den Verweis um. Schreibvorgänge werden in Transaktionsgruppen gesammelt und etwa alle fünf Sekunden mit einem atomar geschriebenen Uberblock „committet“. Ein unterbrochener Commit lässt schlicht den alten, gültigen Zustand stehen, es gibt keinen halb geschriebenen Zwischenzustand. Aus demselben Grund kennt ZFS kein RAID-Write-Hole.

Ein Pool besteht aus einem oder mehreren vdevs (virtuelle Geräte). Daten werden über alle Daten-vdevs verteilt; die Redundanz wird je vdev festgelegt, nicht für den ganzen Pool. Wichtig: Ein Pool ist nur so ausfallsicher wie sein schwächstes Daten-vdev, denn fällt ein vdev komplett aus, ist der ganze Pool verloren.

Neben den Daten-vdevs kennt ZFS spezialisierte Hilfsklassen, mit denen sich Schreib- und Leselast gezielt auf schnelle Geräte verlagern lässt:

ZFS bringt sein RAID selbst mit, es braucht keinen Hardware-RAID-Controller. Drei Bauformen decken unterschiedliche Anforderungen ab:

Jeder Block trägt eine Prüfsumme, die nicht im Block selbst, sondern im verweisenden Block liegt. Beim Lesen prüft ZFS sie und erkennt so stille Datenfehler, die andere Dateisysteme unbemerkt durchreichen. Voreingestellt ist das schnelle fletcher4; für besondere Anforderungen stehen kryptografische Verfahren wie sha256 oder das schnelle blake3 (neuere OpenZFS-Versionen) bereit, daneben weitere Algorithmen.

Liegt Redundanz vor (Mirror oder RAIDZ), repariert ZFS einen als fehlerhaft erkannten Block sofort aus der intakten Kopie, sowohl beim normalen Lesen als auch beim regelmäßigen Scrub, der den gesamten Pool durchliest. Ein monatlicher Scrub gehört zum Pflichtprogramm, um schleichende Fehler vor dem Ernstfall zu finden.

ZFS hält im RAM einen adaptiven Lese-Cache, den ARC. Er gewichtet zwischen zuletzt und häufig genutzten Daten und passt seine Größe dynamisch an. Mehr RAM bedeutet in der Regel deutlich mehr Leseleistung; der ARC nutzt standardmäßig einen Großteil des freien Arbeitsspeichers und gibt ihn bei Bedarf wieder frei. Auf RAM-knappen Systemen lässt sich die Obergrenze über zfs_arc_max begrenzen.

Reicht der RAM nicht, kann eine SSD als L2ARC den Cache verlängern. Sie ist seit OpenZFS 2.0 reboot-persistent, kostet aber selbst etwas ARC für ihre Verwaltung und lohnt erst, wenn der RAM ausgereizt ist. Für viele kleine Random-Reads bringt ein special-vdev (Metadaten und kleine Blöcke auf NVMe) oft mehr als ein L2ARC.

ZFS sammelt alle Writes in Transaktionsgruppen und schreibt sie gebündelt. Synchrone Writes (etwa von Datenbanken, NFS oder iSCSI) müssen aber sofort bestätigt werden. Dafür gibt es das ZFS Intent Log (ZIL): Es protokolliert synchrone Writes, sodass der aufrufende Prozess zurückkehren kann; im Normalbetrieb wird das ZIL nie gelesen, sondern nur nach einem Absturz für das Replay.

Standardmäßig liegt das ZIL im Pool. Ein separates, sehr schnelles Gerät (SLOG) lagert es aus und beschleunigt so ausschließlich synchrone Schreiblast. Bei rein asynchronen Workloads (Backups, Bulk-Kopien) bringt ein SLOG nichts.

ZFS lässt sich über Dataset-Properties fein an den Workload anpassen. Die wichtigsten Stellschrauben:

Dank Copy-on-Write sind Snapshots nahezu kostenlos und in Sekunden erstellt; sie belegen nur den Speicher der seither geänderten Blöcke. Aus einem Snapshot lässt sich ein beschreibbarer Clone ableiten (etwa für Test- oder Vorlagensysteme), und ein Bookmark bewahrt die Information für inkrementelle Übertragungen, ohne die Datenblöcke zu halten.

Mit zfs send/receive wird ein Snapshot als Datenstrom auf ein anderes System übertragen, inkrementell überträgt es nur die geänderten Blöcke. Das ist eine robuste Basis für Backups und Standort-Replikation. Ein Snapshot auf demselben Pool ist allerdings kein Backup; dafür braucht es ein getrenntes Ziel.

Die native Verschlüsselung arbeitet pro Dataset (Default AES-256-GCM). Besonders praktisch fürs Backup: Mit einem verschlüsselten Raw-Send (zfs send -w) gelangen die Daten verschlüsselt auf ein nicht vertrauenswürdiges Ziel, ohne dort je entschlüsselt zu werden.

ZFS kann identische Blöcke deduplizieren. Klassische Dedup führt dafür eine pool-weite Tabelle (DDT), die für akzeptable Leistung im RAM gehalten werden muss und mit der Zahl der Blöcke wächst, also stark von der Blockgröße abhängt. Läuft sie aus dem RAM, bricht die Leistung ein. Deshalb gilt seit jeher: im Zweifel Kompression statt Dedup.

Das mit OpenZFS 2.3 eingeführte Fast Dedup entschärft die schlimmsten Fallstricke (gepufferte DDT-Schreibvorgänge, harte Größenobergrenze per Quota, Prefetch und gezieltes Aufräumen) und macht die Tabelle steuerbar. Ressourcenintensiv bleibt es trotzdem, ein bewusster Sonderfall, kein Standard.

Mit OpenZFS 2.2 kam Block-Cloning (Reflinks): Wird eine Datei kopiert, legt ZFS keine zweite Datenkopie an, sondern lässt beide Dateien auf dieselben Blöcke zeigen und trennt sie erst beim Überschreiben (dateiweises Copy-on-Write). Anders als Deduplizierung braucht das keine teure pool-weite Tabelle und ist im Normalbetrieb praktisch gratis.

Genutzt wird es transparent über cp --reflink=auto, den Kernel-Aufruf copy_file_range() sowie Copy-Offload bei NFS und Samba. Seit OpenZFS 2.3 ist Block-Cloning standardmäßig aktiv. Für das Kopieren identischer Daten ist es der ressourcenschonende Weg, den die klassische Deduplizierung nicht bietet.