OpenZFS Offline-Dedup: Ist ZFS-Dedup endlich praxistauglich?

OpenZFS hat gerade eine deutlich praxistauglichere Methode erhalten, um vorhandene Dateien unter Linux zu deduplizieren: Der Upstream-Master implementiert jetzt FIDEDUPERANGE mithilfe von ZFS Block Cloning. Das bedeutet, dass Tools wie duperemove und bees identische Dateibereiche finden können, nachdem die Daten geschrieben wurden, und ZFS bitten können, diese Blöcke gemeinsam zu nutzen — ohne die klassischen Speicherkosten, jeden Kandidaten in der ZFS-Deduplizierungstabelle vorzuhalten.

Ich habe den tatsächlichen OpenZFS-Commit geprüft, statt mich auf die Forum-Überschrift zu verlassen. Die Änderung wurde am 20. August 2026 committet und ist damit neuer als das stabile OpenZFS 2.4.2, das im Mai veröffentlicht wurde. Es handelt sich also um ein Upstream-Feature, das man beobachten und testen sollte — nicht um etwas, das ich bereits auf einem produktiven TrueNAS-, Proxmox-, Debian- oder Ubuntu-System für verfügbar halten würde.

Was genau hat sich bei der OpenZFS-Deduplizierung geändert?

OpenZFS implementiert jetzt die Linux-Schnittstelle FIDEDUPERANGE, indem es Dateibereiche vergleicht und ZFS Block Cloning einsetzt, wenn die Bereiche byteidentisch sind. Vor dieser Änderung lieferte ZFS für diese Schnittstelle eine Antwort zurück, dass die Operation nicht unterstützt wird.

FIDEDUPERANGE ist eine Linux-Dateisystemschnittstelle, über die ein Userspace-Deduplizierungstool im Grunde sagen kann: „Diese beiden Bereiche sehen identisch aus — kann das Dateisystem das verifizieren und sie sich gemeinsame Speicherplätze teilen lassen?" Die Verantwortung, vor dem Ändern der Speicherreferenzen zu prüfen, ob die Daten tatsächlich übereinstimmen, bleibt beim Dateisystem.

Die OpenZFS-Implementierung führt diese Prüfung innerhalb von ZFS durch. Wo Block-Pointer und starke Prüfsummen ausreichen, um Gleichheit zu belegen, kann sie unnötige Lesevorgänge vermeiden. Wo das nicht ausreicht, liest und vergleicht sie die Daten. Stimmen die Bereiche überein, nutzt sie den vorhandenen Block-Cloning-Mechanismus, sodass die beiden logischen Bereiche dieselben physischen Blöcke referenzieren.

Das unterscheidet sich von einer gewöhnlichen Kopie. Die Dateien bleiben separate logische Dateien. Ändert sich später eine davon, sorgt Copy-on-Write dafür, dass die andere unverändert bleibt.

Das ist eine natürliche Erweiterung des ZFS Block Cloning und ein interessantes Thema für alle, die sich mit ZFS und Storage-Design beschäftigen, weil sich dadurch der Zeitpunkt ändert, an dem man sich zur Deduplizierung von Daten entscheiden kann.

Wie unterscheidet sich Offline-Dedup vom normalen ZFS-Dedup?

Offline-Dedup findet statt, nachdem Daten bereits geschrieben wurden, während das klassische ZFS-Dedup Teil des Schreibpfads ist und Dedup-Kandidaten in einer Deduplizierungstabelle nachverfolgt. Dieser zeitliche Unterschied verändert den Ressourcen-Tradeoff.

Das klassische Inline-ZFS-Dedup kann sofort Speicherplatz sparen, sobald passende Blöcke eintreffen, hat aber den Ruf, teure Metadaten zu erzeugen. Die Deduplizierungstabelle, meist DDT genannt, muss Block-Fingerabdrücke und Referenzen nachverfolgen. Große DDTs können erheblichen Speicher verbrauchen und Performance-Druck erzeugen, wenn sie nicht bequem in RAM und Cache passen.

Der neue FIDEDUPERANGE-Pfad muss die klassische DDT nicht für jeden deduplizierten Block befüllen. Der Upstream-Commit beschreibt das Ziel explizit als das Teilen übereinstimmender Bereiche per Block Cloning, ohne die Speicherkosten der Dedup-Tabelle.

Offline-Dedup verlagert die Kosten auf das Scannen. Ein Tool wie duperemove oder bees muss Duplikat-Kandidaten identifizieren und dann das Dateisystem bitten, sie zu bestätigen und gemeinsam zu nutzen. Das verbraucht CPU, Metadaten-IO und Lesebandbreite zum Zeitpunkt des Scans, statt jedem eingehenden Schreibvorgang dieselbe Art von globalen Lookup-Kosten aufzubürden.

Keines der beiden Modelle ist grundsätzlich besser. Wenn Ihre Workload fortlaufend duplizierte Backup-Blöcke schreibt und eine sofortige Speicherplatzreduktion essenziell ist, kann Inline-Dedup weiterhin sinnvoll sein. Wenn Sie einen großen Dateibaum haben, in dem sich Duplikate über die Zeit ansammeln, und Sie das Scannen in ruhigere Zeiten legen können, lässt sich Offline-Dedup deutlich einfacher durchdenken.

Bedeutet das, dass ZFS-Dedup keinen großen RAM mehr braucht?

Dieser neue Offline-Dedup-Pfad vermeidet die klassischen DDT-Speicherkosten für die Bereiche, die er dedupliziert, macht aber nicht jede ZFS-Deduplizierung speicherplatzneutral. Wenn Sie das normale dedup=on aktivieren, nutzen Sie weiterhin den klassischen Mechanismus oder Fast Dedup samt dessen Metadatenstrukturen.

Diese Unterscheidung ist der wichtigste Teil der Geschichte. „OpenZFS hat den RAM-Verbrauch von Dedup behoben" wäre eine irreführende Überschrift. Was OpenZFS hinzugefügt hat, ist ein weiterer Weg zum Teilen von Speicherplatz, der nicht dasselbe permanent aktive DDT-Design benötigt.

Auch das breitere Fast-Dedup-Projekt verbessert das klassische System weiter. OpenZFS hat Funktionen wie DDT-Quotas, Prefetching, ein Log-Design und Pruning-Arbeit hinzugefügt, damit Inline-Dedup begrenzt und vorhersehbarer verwaltet werden kann. Diese Verbesserungen und Offline-Dedup lösen verwandte Probleme aus unterschiedlichen Richtungen.

Ich würde die Optionen so einordnen:

• Kompression bleibt das Standard-Feature zur Speicherplatzeinsparung, das ich fast überall aktivieren würde.
• Block Cloning spart Speicherplatz, wenn Software absichtlich Reflink-artige Kopien erzeugt.
• Offline-Dedup findet Duplikatdaten nachträglich und wandelt identische Bereiche in gemeinsam genutzte Blöcke um.
• Inline-Dedup versucht, doppelte Blöcke bereits beim Schreiben zu erkennen.

Sobald man diese vier Mechanismen auseinanderhält, lässt sich das ZFS-Design viel einfacher diskutieren.

Kann ich OpenZFS-Offline-Dedup schon heute nutzen?

Nicht sicher, wenn Sie davon ausgehen, dass Ihr aktuelles stabiles Paket es bereits enthält. Der betreffende Commit landete am 20. August 2026 im Upstream-Master von OpenZFS, während OpenZFS 2.4.2 am 12. Mai 2026 veröffentlicht wurde.

Stand 21. August bedeutet das: Bei einem normalen System mit dem stabilen Release 2.4.2 sollte man annehmen, dass dieser Commit nicht enthalten ist, sofern der jeweilige Anbieter ihn nicht selbst zurückportiert hat. Auch das Distributions-Packaging kann dem Upstream hinterherhinken, und Appliance-Produkte qualifizieren Dateisystem-Änderungen häufig nach ihrem eigenen Zeitplan.

Prüfen Sie vor einem Test den genauen OpenZFS-Build Ihres Betriebssystems oder Ihrer Appliance und lesen Sie dessen Release Notes. Auf einem Proxmox-Host zählen der Proxmox-Kernel und die ZFS-Pakete mehr als die Existenz eines GitHub-Commits. Bei TrueNAS zählt die TrueNAS-Release-Linie. Bei Debian oder Ubuntu zählt die Version des Distributionspakets.

Wenn Sie mit Upstream-Code experimentieren möchten, nutzen Sie zunächst entbehrliche Daten. Dateisystem-Features verdienen eine höhere Messlatte als Anwendungs-Features, weil ein Absturz einen ganzen Pool betreffen kann, nicht nur einen einzelnen Prozess.

Wer ZFS unter Virtualisierung betreibt, sollte die Storage-Änderung außerdem getrennt von Hypervisor-Upgrades behandeln. Wenn Sie ohnehin gerade ein Proxmox-VE-8-auf-9-Upgrade planen, würde ich experimentellen OpenZFS-Master-Code nicht im selben Zeitfenster einführen.

Wie bleibt FIDEDUPERANGE sicher, wenn sich eine Datei während des Dedup ändert?

Die OpenZFS-Implementierung vergleicht und klont Bereiche unter Locking, sodass die geteilten Bytes tatsächlich die verglichenen Bytes sind. Das ist essenziell, weil ein Offline-Tool Kandidaten im Userspace identifizieren kann, aber nur das Dateisystem sicher entscheiden kann, ob die Bereiche auf der Platte im Moment der Deduplizierung noch identisch sind.

Der Commit behandelt auch Bereiche, die bereits gemeinsam genutzt werden. In diesem Fall kann OpenZFS den Bereich als dedupliziert melden, ohne unnötig Blockreferenzen neu zu schreiben.

Eine weitere gute Designentscheidung: Die Dedup-Operation ändert den Dateiinhalt nicht und muss sich deshalb nicht wie ein normaler Schreibvorgang verhalten. Die Implementierung behandelt die Operation nicht schon deshalb als Inhaltsänderung, weil Speicherreferenzen gemeinsam genutzt werden.

Deshalb ist native Unterstützung im Dateisystem so wichtig. Ein Userspace-Tool sollte nicht versuchen, Deduplizierung vorzutäuschen, indem es Dateien hinter dem Rücken der Anwendungen umschreibt. Es sollte Kandidaten identifizieren und das Dateisystem bitten, die sichere Referenzoperation durchzuführen.

Welche Workloads profitieren am meisten von Offline-ZFS-Dedup?

Offline-ZFS-Dedup ist dort am attraktivsten, wo bereits Duplikatdaten in gewöhnlichen Dateien vorliegen und sich das Scannen außerhalb des kritischen Schreibpfads einplanen lässt. Backup-Repositories, wiederholte VM-Image-Exporte, ISO-Sammlungen, Home-Verzeichnisse von Nutzern, Software-Build-Bäume und Content-Archive sind naheliegende Kandidaten zum Testen.

Die tatsächliche Ersparnis hängt von der Duplizierung auf Block- und Bereichsebene, der Dateiblockgröße, Kompression, Verschlüsselungsverhalten und davon ab, wie der Scanner Kandidaten findet. Ein Verzeichnis voller Dateien mit ähnlichen Namen ist nicht zwangsläufig deduplizierbar. Ein Verzeichnis voller byteidentischer VM-Templates vermutlich schon.

Backups sind interessant, weil moderne Backup-Anwendungen oft ihr eigenes Chunking, ihre eigene Kompression und Deduplizierung durchführen. Dateisystem-Dedup unterhalb eines bereits deduplizierten Repositorys auszuführen, spart womöglich wenig und erzeugt zusätzliche Scan-IO. Die richtige Frage lautet nicht „funktioniert Offline-Dedup?", sondern „wie viele physische Bytes spart es auf diesem Repository, wenn man die Scan-Kosten einrechnet?"

Ich würde im Labor vier Dinge messen: gesparte Bytes, Scandauer, erzeugte Lese-IO und die Auswirkung auf spätere Schreibvorgänge auf deduplizierte Dateien. Wenn das Tool 3 Prozent der Kapazität spart, dabei aber jede Nacht 40 TB liest, ist das vermutlich ein schlechter Deal. Wenn es 35 Prozent eines größtenteils statischen Archivs während eines wöchentlichen Scans mit niedriger Priorität spart, ist das deutlich interessanter.

Ist das endlich das ZFS-Dedup-Feature, das die meisten Nutzer verwenden sollten?

Für viele Nutzer, die dedup=on gemieden haben, weil sie keine große, permanent aktive DDT wollten, ist Offline-Dedup das erste ZFS-Dedup-Modell, das ich ernsthaft zum Testen in Betracht ziehen würde. Es passt zu der Art, wie Administratoren ohnehin über Wartungsjobs denken: Verschwendung finden, zurückgewinnen, dann das System wieder in den Normalbetrieb überführen.

Ich würde Kompression weiterhin als Standard behalten und Inline-Dedup deaktiviert lassen, sofern die Workload nicht beweist, dass sie die zusätzliche Komplexität verdient. Der neue Offline-Pfad ist gerade deshalb attraktiv, weil er eine zusätzliche Option bietet, ohne den Schreibpfad zu zwingen, Deduplizierung für jeden einzelnen Block für immer zu lösen.

Der limitierende Faktor heute ist die Verfügbarkeit. Der Code ist upstream gemergt, aber das stabile OpenZFS 2.4.2 stammt aus der Zeit davor. Ich würde auf den ersten stabilen Release oder Vendor-Build warten, der den Commit enthält, duperemove oder bees gegen eine Kopie realer Daten testen und die Entscheidung anhand gemessener Einsparungen treffen.

An diesem Punkt wird ZFS-Dedup für gewöhnliche Storage-Admins interessanter. Die Frage ändert sich von „kann ich es mir leisten, Dedup für diesen gesamten Datensatz einzuschalten?" zu „lohnt es sich, diese Duplikatdaten nachträglich zu bereinigen?"