ZFS ist eine Meisterleistung der Storage-Technik. Copy-on-Write, Checksummen, Snapshots, integrierte Komprimierung, RAID-Z – alles auf Enterprise-Niveau. Aber gerade im Homeserver ist ZFS oft overkill – und das liegt nicht an fehlenden Features, sondern an den Ressourcen, die es stillschweigend erwartet.
ZFS: kein "set and forget"
Das Problem mit ZFS ist nicht die Konfiguration – ein zpool create tank mirror /dev/sda /dev/sdb ist schnell getippt. Die Sache ist: ZFS nimmt sich, was es kriegen kann, ohne zu fragen.
| Aspekt | ZFS | Btrfs |
|---|---|---|
| RAM-Nutzung (ARC) | 50 % des verbauten RAMs als Default | kein vergleichbarer Cache |
| Minimalempfehlung RAM | 8 GB (mit Dedup eher 32+) | 512 MB reichen |
| CPU unter Last | höher (Checksummen + Kompression) | moderat |
| Hitzetoleranz bei voller Platte | droppt Leistung massiv | gleichmäßiger |
| Snapshots | ja | ja |
| RAID-Ähnlich | RAID-Z1/2/3 (jeder Fehler = Resilver) | RAID 0/1/10 + DUP |
| Datenintegrität | Checksummen auf allen Ebenen | Checksummen (metadata optional data) |
| Kernel-Integration | DKMS / Out-of-tree (OpenZFS) | nativ im Kernel |
Warum ZFS im Homeserver oft zu schwer ist
1. RAM-Fresser ohne Rücksicht
ZFS' ARC (Adaptive Replacement Cache) belegt standardmäßig bis zu 50 % des gesamten RAMs. Auf einem Homeserver mit 16 GB sind das 8 GB – für einen Dateisystem-Cache. Ja, man kann das Limit per zfs_arc_max senken, aber der Default ist aggressiv.
Auf einem Btrfs-System fließt der freie RAM in den Page Cache – wenn das System ihn braucht, gibt er ihn frei. Unkomplizierter.
2. Performance fällt ohne Konfiguration ab
Ein ZFS-Pool frisch installiert, ein zpool create und los geht's – die Geschwindigkeit kann enttäuschend sein. Grund: ZFS erwartet Tuning.
Typische Stellschrauben:
ashift: Default liegt oft bei 9 (512 Bytes). Auf modernen 4K-Sektoren-Platten braucht esashift=12– sonst massive Schreibleistungseinbußen.recordsize: Default 128 KB. Für Datenbanken oder VMs falsch.atime/relatime: Default on – für viele Setups unnötiger Overhead.compression: lz4 ist quasi kostenlos – bis die CPU unter Last kommt.xattr/acl: wenig bekannt, aber relevant bei Samba/NFS.
Wer diese Parameter nicht setzt, lässt teils 30–50 % Performance liegen. Btrfs läuft bei den wichtigsten Werten direkt gut.
3. Resilver und Fehlertoleranz
ZFS' RAID-Z ist großartig – wenn ein Laufwerk ausfällt, wird der Resilver zur Zitterpartie. Ein Resilver unter Last kann das System lahmlegen, weil ZFS rechnen muss. Auf kleinen Homeservern mit wenig RAM und schwacher CPU ist das spürbar. Btrfs' RAID 1 shadowt die Daten blockweise – bei Ausfall wird einfach vom Mirror gelesen.
4. Kein natives Reshaping
Ein RAID-Z kann nicht einfach um ein Laufwerk erweitert werden (zumindest nicht ohne die inzwischen hinzugekommene RAID-Z Erweiterung, die noch nicht als stabil abgeschlossen gilt). Ein Btrfs-RAID 1 lässt sich dagegen mit btrfs device add erweitern.
5. Kernel-Abhängigkeit
ZFS ist nicht im Linux-Kernel (Lizenzkonflikt). Jedes Kernel-Update kann bedeuten: ZFS neu kompilieren, warten, hoffen. Btrfs ist ab kernel 3.x dabei und läuft immer.
Was Btrfs besser macht
Einfache Administration
# Subvolumes anlegen (Docker, @home, @snapshots)
btrfs subvolume create @docker
btrfs subvolume create @home
# Snapshot per systemd-timer
btrfs subvolume snapshot -r @docker @docker-$(date +%Y%m%d)
# Kompression aktivieren (mount)
mount -o compress=zstd /dev/sda /mntKein Pool-Erstellen, kein Import/Export, keine Online-Resilver-Rate. Die Befehle sind knapp und der Output ist lesbar.
Integration mit systemd und snapper
Snapper + systemd-timer = Snapshots ohne eigenes Tooling. Mit ZFS bräuchte man sanoid oder znapzend.
Speicher-effizienter bei kleinen Platten
Auf einem 1-TB-SSD + 2-TB-HDD-Setup kann ZFS seinen ARC-Cache nicht sinnvoll füllen – die 8 GB RAM sind trotzdem reserviert. Btrfs passt sich automatisch an.
Entscheidungsmatrix
| Szenario | Empfehlung |
|---|---|
| Homeserver (8–16 GB RAM, 2–4 Platten) | Btrfs |
| Dedizierter NAS (TrueNAS, 32+ GB RAM) | ZFS |
| Ein-Platten-Laptop / Desktop | Btrfs |
| VM-Server mit vielen Snapshots | Btrfs (subvolumes) |
| Produktivdatenbank mit 10+ TB | ZFS |
| Raspberry Pi / Low-RAM-Gerät | Btrfs |
| Enterprise Storage mit 128+ GB RAM | ZFS |
Fazit
ZFS ist ein außergewöhnliches Dateisystem – für die richtige Umgebung. Wer einen TrueNAS-Server mit 64 GB RAM und vielen Platten betreibt, ist mit ZFS exzellent bedient.
Im Homeserver dagegen fordert ZFS oft Leistungsreserven, die man gar nicht hat, und bestraft fehlende Konfiguration mit spürbaren Einbußen. Btrfs ist weniger spektakulär, aber wesentlich genügsamer, tiefer im Kernel verwurzelt, und für den Alltag auf überschaubarer Hardware die stressfreiere Wahl.
Ich setze seit Jahren auf Btrfs mit zstd-Kompression, systemd-timer-Snapshots und Docker auf btrfs-subvolumes. Es läuft, es ist schnell, und es nervt nicht.