In meinem Vergleich Btrfs vs. ZFS habe ich ZFS im Homeserver abgelehnt. Zu viel RAM, zu viel Konfiguration, zu viel Overhead. Btrfs sei die stressfreiere Wahl, ZFS nur was für TrueNAS mit 64 GB RAM und Reihen von Festplatten.
Nun ja. Ich habe aufgerüstet – neuer Server, 64 GB RAM, und ich dachte: Warum nicht nochmal versuchen? Und es läuft. Gut sogar.
Ob es am Speicher liegt oder an meiner Dummheit im ersten Versuch, ist noch nicht abschließend geklärt. Aber ich will ehrlich sein: Ich habe mich geirrt.
Was war mein Problem mit ZFS?
Mein erster Versuch lief auf einem Server mit 16 GB RAM. ZFS hat seinen ARC-Cache brav genommen – 8 GB davon. Dazu kam, dass ich keine Ahnung von ashift, recordsize und den anderen Stellschrauben hatte. Das Ergebnis: mäßige Performance, hoher RAM-Verbrauch, Frust.
Mein Fazit damals: ZFS ist overkill für den Homeserver.
Was sich geändert hat
Mehr RAM – der Game Changer
64 GB RAM sind für ZFS ein ganz anderes Spielfeld. Der ARC hat jetzt genug Platz, um sich sinnvoll zu füllen, ohne dass das System darunter leidet. Die 50-Prozent-Regel sind 32 GB Cache – davon merke ich nichts.
| RAM | ARC (Default) | Effekt |
|---|---|---|
| 16 GB | 8 GB | System leidet, Pages werden verdrängt |
| 32 GB | 16 GB | Geht, aber knapp |
| 64 GB | 32 GB | Komfortzone – genug für alles |
Auf 16 GB war ZFS ein Geier, der mehr nimmt als er braucht. Auf 64 GB ist er ein Kavalier, der sich bedient, aber genug für alle übrig lässt.
Richtig konfiguriert
Diesmal habe ich mir Zeit genommen:
# Pool anlegen mit richtigen Werten
zpool create -o ashift=12 tank raidz2 /dev/sd{a,b,c,d}
# Dataset für Docker
zfs create -o recordsize=16K -o compression=lz4 tank/docker
zfs set atime=off tank/docker
# Dataset für VMs
zfs create -o recordsize=128K -o compression=lz4 tank/vms
zfs set atime=off tank/vmsashift=12 statt dem Default von 9 – das allein hat die Schreibleistung spürbar verbessert. recordsize angepasst je nach Einsatzszene. lz4 als Kompression – quasi kostenlos.
Was ich anders mache als beim ersten Mal
- Kein ZFS auf dem Rootfilesystem – nur für Daten und VMs
- Kein LUKS mehr – native ZFS-Verschlüsselung statt Blocklayer
- Snapper statt sanoid – gewohntes Interface, gleiche Funktionalität
- ARC-Limit gesetzt –
zfs_arc_maxauf 24 GB, Rest für System - Monitoring –
zpool status,zfs list,arcstatim Auge behalten
Was besser läuft als erwartet
Snapshots
ZFS-Snapshots sind instant – egal wie groß der Dataset ist. Ein zfs snapshot tank/docker@vor-Update ist in 0.1 Sekunden erledigt.
Kompression
lz4 ist tatsächlich fast kostenlos. Die Daten werden komprimiert, ohne dass ich CPU merke. Bei Text-Logs und Datenbanken spart das 30–50 % Speicherplatz.
Checksummen
Alle Daten werden auf Integrität geprüft. Das ist im Homeserver vielleicht overkill – aber wenn eine Platte bitrot hat, möchte ich das wissen. Btrfs kann das auch, aber ZFS macht es durchgängig auf allen Ebenen.
Native Verschlüsselung
Vorher hatte ich LUKS als Zwischenschicht unter Btrfs – erst den Blocklayer verschlüsseln, dann das Dateisystem drauf. Das funktionierte, aber es war eine zusätzliche Komplexität: cryptsetup open, Passphrase eingeben, Pool mounten. Bei jedem Boot.
ZFS kann das jetzt nativ:
# Pool mit Verschlüsselung anlegen
zpool create -o ashift=12 -O encryption=on \
-O keylocation=file:///etc/zfs/keys/tank.key \
-O keyformat=hex tank raidz2 /dev/sd{a,b,c,d}Kein LUKS mehr, kein cryptsetup, keine initramfs-Hacks. ZFS verschlüsselt auf Dataset-Ebene – und man kann das Passwort oder den Key ändern, ohne die Daten umzukopieren. Dazu kommt: ZFS-Encryption ist integriert, nicht eine Schicht darunter. Snapshots bleiben verschlüsselt, Replication funktioniert ohne Entschlüsselung auf dem Zielserver.
Was ich nicht vermisse
- Den RAM-Verbrauch – nicht auf 64 GB, schon gar nicht
- Die Komplexität – ja, ZFS ist komplexer als Btrfs. Aber mit
- Die Kernel-Abhängigkeit – ja, OpenZFS muss zum Kernel passen.
den richtigen Werten ist es "set and forget" Aber seit ein paar Jahren läuft das erstaunlich stabil
Fazit
Ich habe mich geirrt. ZFS auf einem Homeserver mit 16 GB RAM ist wirklich eng – da ist Btrfs die bessere Wahl. Aber auf einem Server mit genug Ressourcen ist ZFS ein solides, zuverlässiges Dateisystem mit Features, die Btrfs nicht bieten kann.
Mein altes Urteil gilt nur für die eine Konstellation:wenig RAM, wenig Erfahrung, wenig Konfiguration. Wer mehr mitbringt, ist mit ZFS gut beraten.
64 GB RAM sind, wie sich herausstellt, der Unterschied zwischen "ZFS ist overkill" und "ZFS läuft perfekt". Oder zwischen meinem ersten und meinem zweiten Versuch. Wahrscheinlich beides.