Dateisystem zfs (ZoL = ZFS on Linux)

zfs ist ein von Solaris kommendes Dateisystem, das einige Vorzüge in sich vereint, u.a.:

• Copy-on-Write / Journalling
• Prüfsummen über Datenblöcke (kann dadurch selbst entscheiden, ob bzw. welche Daten korrekt sind)
• RAID-Funktionen: mirror (RAID1), raid-z1 (RAID5), raid-z2 (RAID6)
• Kompression
• Verschlüsselung (nur in relativ neuen Releases von ZoL, z.B. auf Debian 11)
• Snapshots
• Deduplikation (Vorsicht: braucht viel RAM!)
• LVM-artige Funktionen

Vorteile im RAID-Betrieb

• wenn Daten auf einem Datenträger z.B. eines Mirrors korrupt sind, weiss ZFS, welche korrupt und welche ok sind durch die Prüfsummen und muss sich nicht auf Fehlermeldungen der HDDs/SSDs verlassen. Bei einem "Scrub" koennen korrupte Blöcke gefunden und korrigiert neu geschrieben werden (gut gegen "bit rot").
• wenn ein Datentraeger getauscht werden muss, weiss zfs, welche Blöcke wirklich benutzt sind und muss nur diese neu synchronisieren (nicht den leeren Platz)
• kein HW-RAID-Controller + zugehörige hersteller-spezifische SW-Tools notwendig

Linux-Distributionen, die ZoL unterstützen

• Ubuntu (experimentell, seit 16.04. seit 20.04 im Desktop-Installer)

• Debian (seit "BullsEye" 11, siehe zfs-dkms Package)

• Proxmox VE (und im Gegensatz zu md-RAID wird ZFS-mirror auch von den Entwicklern supported)

Tipps

Partitionierung

• macht Euch 2GB große /boot-Partition(en) - 500MB reichen definitiv nicht!
• es sieht so aus, als ob Ubuntu 20.04 für /boot einen separaten "bpool" haben will ("/" u.a. == rpool).
• /boot separat, weil: grub kann nicht alle zfs-Features. encrypted root-fs geht ohne auch nicht.
• die ca. 8MB GPT-Partition 9 "Solaris reserved" ganz hinten auf der Disk hat wohl historische Gründe und wird von Linux nicht benutzt

Fehlererkennung

• scrub sollte regelmäßig (z.B. sonntags) laufen, so dass kleinere Fehler automatisch korrigiert und größere Probleme früh erkannt werden

Boot-Problem: rpool kann nicht importiert werden

Tritt gerne nach Upgrade auf 20.04 auf.

Man landet dann auf dem initramfs-Prompt. Probiert man dort zpool import, kommt ein Hinweis, dass das Filesystem woanders importiert ist.

Wenn man sich sicher ist, dass das nicht der Fall ist, kann man via zpool import -f rpool es forcieren.

Boot-Problem: /var/cache kann nicht gemounted werden

Tritt oft direkt nach o.g. Problem auf. Ursache ist, dass das Verzeichnis /var/cache nicht leer ist und sich zfs daher weigert darauf zu mounten.

Lösungen:

• erstmal schauen, was da drin liegt. Da es ein Cache ist, ist es normalerweise nicht wichtig und kann gelöscht werden.
• falls es immer wieder kommt, kann man per zfs-Option "overlay=on" auch einstellen, dass auch auf nicht-leere Verzeichnisse gemountet wird

Speicherverwaltungs-Konflikte?

Ich habe es schon erlebt, dass zfs irgendwie instabil war.

Man hatte den Eindruck, dass sich zfs und Linux sich um's RAM schlagen und es dabei manchmal nur Verlierer gibt.

Abhilfe: Speicherverbrauch von ZFS limitieren, z.B. auf 8GB:

# /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=8589934592

Danach (wenn man zfs als root-Filesystem hat):

update-initramfs -u

Wichtige Kommandos

Mirror / RAID / Pool - Status checken

zpool status

Snapshot erstellen

Kann man z.B. vor größeren Änderungen (wie Upgrades) machen:

zfs snapshot -r rpool@before-upgrade-to-xxxx

Mirror: Datenträger ersetzen

# falls zu entfernender DT noch im Pool ist:
zpool detach rpool /dev/disk/by-id/<bad-disk>-partN

# dann neuen/leeren DT identisch partitionieren wie vorhandenen DT mit Daten

# Spiegel neu zusammenbauen:
zpool attach rpool /dev/disk/by-id/<existing-disk-with-data>-partN /dev/disk/by-id/<new-disk-empty>-partN

# danach sollte es alle benutzten Datenblöcke auf die leere Disk-Partition kopieren "resilvering"...
zpool status

Verschlüsselung

zpool create rpool mirror /dev/disk/by-id/<disk1>-partN /dev/disk/by-id/<disk2>-partN
zpool set feature@encryption=enabled rpool
zfs create -o encryption=aes-256-ccm -o keyformat=passphrase rpool/ccm
zfs create -o encryption=aes-256-gcm -o keyformat=passphrase rpool/gcm
zfs create -o encryption=off rpool/none

gcm war in meinen Versuchen beim Lesen ca. doppelt so schnell wie ccm (default). Beim Schreiben war die Geschwindigkeit ähnlich.

Test-Umgebung: Virtualbox VM auf Xeon E5-2667v2 Workstation (HW mit AES-NI).