ZFS (Zettabyte File System)

ZFS ist nicht bloß ein Dateisystem, sondern ein hybrides Speichermanagement-System, das die Funktionen eines Filesystems und eines Logical Volume Managers (LVM) verschmilzt.

In traditionellen Architekturen (z. B. ext4 auf LVM) sind das Dateisystem und die physische Festplattenverwaltung getrennt. Das Dateisystem „sieht“ nicht, wenn ein darunterliegender Block korrupt ist. ZFS eliminiert diese Blindheit, indem es beide Schichten kontrolliert. Das Ziel ist nicht primär Geschwindigkeit, sondern absolute Datenintegrität.

Kernmechaniken: Das „Warum“ hinter der Technik

Copy-on-Write (CoW)

Klassische Dateisysteme überschreiben Datenblöcke bei Änderungen („Update-in-Place“). Wenn während dieses Schreibvorgangs der Strom ausfällt, ist der Block inkonsistent.

ZFS nutzt Copy-on-Write. Wenn du eine Datei änderst:

1. Schreibt ZFS die neuen Daten in einen neuen, freien Block.
2. Aktualisiert dann die Metadaten-Pointer, um auf den neuen Block zu zeigen.
3. Gibt erst nach erfolgreichem Schreiben den alten Block zur Überschreibung frei (sofern kein Snapshot darauf zugreift).

Architektonische Konsequenz:

• Das Dateisystem ist auf der Festplatte immer in einem konsistenten Zustand.
• Es gibt kein fsck (File System Check) nach Abstürzen, da defekte Transaktionen beim nächsten Mount einfach ignoriert werden (sie wurden nie „committed“).

Merkle Tree & Checksummen

ZFS vertraut der Festplatte nicht. Jeder Datenblock erhält eine Prüfsumme (Checksum). Diese Prüfsumme wird jedoch nicht beim Datenblock selbst gespeichert, sondern im Parent-Block (dem Pointer, der auf die Daten zeigt).

Das zieht sich durch den gesamten Baum bis zum Root-Block hoch (Merkle Tree).

Kausalität:

Wenn ein Bit auf der Platte kippt („Bit Rot“), stimmt die berechnete Prüfsumme beim Lesen nicht mit der im Parent-Block gespeicherten überein.

• Bei Mirror/RAID-Z: ZFS erkennt den Fehler, holt die korrekten Daten aus der Parität/Spiegelung, liefert die korrekten Daten an die Applikation und repariert den defekten Block im Hintergrund („Self-Healing“).
• Bei Single-Disk: ZFS meldet einen E/A-Fehler, statt korrupte Daten an die Anwendung zu übergeben.

Storage-Hierarchie (Der „Pool“)

ZFS abstrahiert physische Disks zu einem Storage Pool (zpool). Datasets (Dateisysteme) bedienen sich dynamisch aus diesem Pool, statt starre Partitionen zu nutzen.

VDEVs (Virtual Devices)

Der Pool besteht aus einem oder mehreren VDEVs. Ein VDEV ist die Redundanz-Einheit. Fällt ein ganzes VDEV aus, ist der gesamte Pool verloren.

Wichtig: Ein RAID-Z VDEV kann (stand heute in den meisten stabilen Implementierungen) nachträglich nicht um einzelne Disks erweitert werden. Du musst ein neues VDEV zum Pool hinzufügen, um Kapazität zu gewinnen.

Spezielle VDEV-Klassen

Du kannst die Performance gezielt tunen, indem du Lasten auf SSDs/NVMe auslagerst:

• LOG (SLOG/ZIL): Nur für synchrone Schreibvorgänge (z. B. Datenbanken, NFS). ZFS schreibt den Intent Log (ZIL) auf dieses schnelle Device, bevor es den langsamen Pool-Commit macht. Beschleunigt nicht das sequentielle Schreiben großer Dateien.
• CACHE (L2ARC): Erweiterung des RAM-Caches auf SSD. Nur sinnvoll, wenn der RAM bereits maximiert ist (siehe Abschnitt 4).
• SPECIAL: Speichert Metadaten (und optional kleine Blöcke) auf SSDs. Beschleunigt das Durchsuchen von Verzeichnissen (ls -la, find) auf HDD-Pools massiv. Fällt das SPECIAL-VDEV aus, ist der Pool defekt (muss also redundant sein!).

Caching & Performance (ARC)

ZFS nutzt den ARC (Adaptive Replacement Cache), der im RAM liegt. Im Gegensatz zum simplen LRU (Least Recently Used) anderer Systeme, balanciert ARC zwischen:

1. MRU (Most Recently Used): Was hast du gerade angefasst?
2. MFU (Most Frequently Used): Was fasst du oft an?

Architektur-Entscheidung:

ZFS belegt standardmäßig fast den gesamten freien RAM für den ARC. Das ist gewollt („Unused RAM is wasted RAM“). Sobald Applikationen Speicher brauchen, gibt ZFS diesen sofort frei.

[SCREENSHOT: Übersicht der RAM-Verteilung in TrueNAS/Proxmox (ARC, Services, Free)]

Der L2ARC-Mythos:

L2ARC (SSD Cache) verbraucht RAM, um seine Index-Tabelle zu verwalten.

• Faustregel: Füge kein L2ARC hinzu, wenn du weniger als 64 GB RAM hast. Oft ist mehr RAM effektiver als eine Cache-SSD.

Features & Implikationen

Snapshots & Clones

Dank CoW kosten Snapshots initial null Speicherplatz. Ein Snapshot ist lediglich ein Zeitstempel, der verhindert, dass Blöcke, die zu diesem Zeitpunkt existierten, freigegeben werden. Erst wenn sich Daten ändern, wächst der Snapshot (Delta).

• Send/Recv: ZFS kann Snapshots inkrementell an einen anderen Pool senden. Das ist effizienter als rsync, da ZFS auf Block-Ebene genau weiß, was sich geändert hat, ohne das Filesystem scannen zu müssen.

Kompression

Die Aktivierung von LZ4 oder ZSTD Kompression erhöht oft die Performance.

• Kausalität: CPUs sind heute extrem schnell, Festplatten (I/O) langsam. Es geht schneller, komprimierte Daten zu schreiben und im RAM zu entpacken, als unkomprimierte Daten auf die langsame Platte zu schreiben.

Deduplizierung (Warnung!)

Deduplizierung eliminiert identische Blöcke.

• Das Problem: ZFS benötigt eine „Deduplication Table“ (DDT), die im RAM liegen muss.
• Faustformel: ~1-5 GB RAM pro 1 TB Daten nur für die Tabelle.
• Risiko: Läuft der RAM voll und die DDT muss auf die Platte ausgelagert werden, bricht die Performance dramatisch ein („Thrashing“). In 99% der Fälle ist Deduplizierung für General-Purpose-Workloads ein Architekturfehler.

Fazit & Einsatzbereiche

ZFS ist der De-Facto-Standard für Software-Defined Storage, wenn Datenintegrität wichtiger ist als rohe Geschwindigkeit auf Einzelplatzsystemen.

Einsatz-Checkliste:

• Nutzung von ECC-RAM wird dringend empfohlen (aber ZFS läuft auch ohne, verliert nur eine Schutzschicht im RAM selbst).
• Kein Hardware-RAID-Controller nutzen! ZFS benötigt direkten Zugriff auf die Disks (HBA-Mode / IT-Mode), um SMART-Werte zu lesen und Sektoren direkt zu adressieren.
• Ideal für: NAS (TrueNAS), Hypervisor-Storage (Proxmox), Backup-Server.

This post is also available in: