Compression

ZFS kann Daten transparent beim Schreiben komprimieren und beim Lesen dekomprimieren. Bei heutigen CPUs merkt man davon nichts — im Gegenteil: Weil weniger Daten auf die Platte geschrieben werden müssen, sinkt die I/O-Last und es wird oft sogar schneller. Man bekommt also mehr Platz und mehr Performance gleichzeitig.

Wichtig: Beim Aktivieren werden nicht rückwirkend alle Daten komprimiert. Nur neue Schreibvorgänge werden komprimiert abgelegt. Schaltet man Compression wieder ab, bleiben die komprimierten Daten lesbar — neue Daten werden unkomprimiert geschrieben.

Aktivieren:

zfs set compression=lz4 pool/dataset

LZ4 ist heute der empfohlene Algorithmus — schnell, niedriger CPU-Verbrauch, gutes Kompressionsverhältnis. Es ist seit OpenZFS 0.7 und FreeBSD 12 der Default bei compression=on. Alternativ gibt es gzip (Level 1–9, stärkere Kompression aber mehr CPU) und zstd (seit OpenZFS 2.0, guter Kompromiss zwischen gzip und lz4).

Für Daten, die bereits komprimiert sind (Videos, Bilder, Archive), bringt Compression nichts — ZFS erkennt das und legt solche Blöcke unkomprimiert ab. Für Logfiles, Konfigurationen, VMs und Datenbanken lohnt es sich fast immer.

Compression in der Praxis

Test mit einer frischen Betriebssystem-Installation auf zwei baugleichen Rechnern — einmal mit, einmal ohne Compression:

# Kompressionsverhältnis prüfen
zfs get compressratio rpool
NAME   PROPERTY       VALUE  SOURCE
rpool  compressratio  1.52x  -

# Plattenverbrauch mit Compression
zpool list
NAME    SIZE  ALLOC   FREE    CAP  HEALTH
rpool    74G  2,59G  71,4G     3%  ONLINE

# Plattenverbrauch ohne Compression
zpool list
NAME    SIZE  ALLOC   FREE    CAP  HEALTH
rpool    74G  3,93G  70,1G     5%  ONLINE

2,59 GB statt 3,93 GB — ein Drittel weniger Plattenverbrauch bei einer Standard-Installation. Die Installation dauerte mit Compression etwa 30 Sekunden länger.

Algorithmus-Wahl

Pro Dataset lässt sich der Algorithmus und Level anpassen:

# LZ4 — schnell, empfohlen für fast alles
zfs set compression=lz4 pool/data

# gzip-9 — maximale Kompression, mehr CPU
zfs set compression=gzip-9 pool/archiv

# zstd — seit OpenZFS 2.0, guter Kompromiss
zfs set compression=zstd pool/logs

# Prüfen
zfs get compression pool/data

Deduplication

Bei aktivierter Deduplication werden identische Blöcke nur einmal gespeichert. ZFS bildet für jeden Block eine SHA-256-Checksumme — existiert ein Block mit derselben Checksumme bereits, wird nur ein Verweis angelegt statt die Daten erneut zu schreiben.

Das spart Platz bei VMs (viele identische OS-Blöcke), Fileservern (dasselbe Dokument an verschiedenen Stellen) oder Versionierungs-Kopien. Aktivieren:

zfs set dedup=on pool/vms

Für zusätzliche Sicherheit gegen Hash-Kollisionen kann man einen Byte-für-Byte-Vergleich erzwingen:

zfs set dedup=sha256,verify pool/vms

Dedup-Warnung: RAM-Verbrauch

Deduplication frisst RAM. Die Dedup-Tabelle (DDT) muss im Arbeitsspeicher gehalten werden — pro Block ein Eintrag. Faustformel: ~320 Bytes pro Block, bei 128K-Blockgröße also ~2,5 GB RAM pro TB gespeicherter Daten. Passt die DDT nicht mehr in den RAM, wird sie auf die Platte ausgelagert und die Performance bricht dramatisch ein.

Ob sich Dedup lohnt, kann man vorher mit einem Trockenlauf prüfen — zdb -S pool zeigt das erwartete Dedup-Ratio ohne tatsächlich zu deduplizieren. In den meisten Fällen ist Compression allein die bessere Wahl: weniger Komplexität, kein RAM-Overhead, und der Platzvorteil ist oft vergleichbar.

Mehr zu ZFS: TRIM im ZFS-Pool aktivieren und Linux Mint mit verschlüsseltem ZFS Root Pool. Fragen? Einfach melden.