OpenZFS 2.4.2: Kritische Fixes für dRAID, Rebuilds und Linux-Kernel-Kompatibilität

OpenZFS 2.4.2 ist am 12. Mai 2026 erschienen – kein Feature-Release, sondern ein Maintenance-Update mit konkreten Datenintegritäts-Fixes, die in produktiven Setups echte Risiken abwenden. Wer dRAID betreibt, Block Cloning nutzt oder seinen Kernel-Stand regelmäßig aktualisiert, sollte die Release Notes kennen, bevor er entscheidet, ob das Update sofort oder nach dem nächsten Wartungsfenster kommt.

Was OpenZFS 2.4.2 konkret behebt

Das Release adressiert eine Reihe von Bugs, die in spezifischen aber nicht exotischen Szenarien zu ernsthafter Datenkorruption führen konnten. Am kritischsten ist der Fix für dRAID-Checksum-Probleme bei degradierten Disks: Wer nach einem Disk-Ausfall einen Rebuild laufen ließ, riskierte in bestimmten Konstellationen fehlerhafte Checksummen – ohne dass ZFS das von sich aus bemerkte. Das ist genau die Klasse von Bug, gegen die das gesamte Integritätsmodell von ZFS eigentlich schützen soll.

Hinzu kommt ein Fix für Datenkorruption nach dem Löschen oder Zurücksetzen einer Disk in dRAID-Setups. In der Praxis passiert das bei jedem geplanten Disk-Tausch im laufenden Betrieb – kein Edge-Case für ein produktives NAS oder einen Storage-Server mit mehreren Dutzend Terabyte. Ebenfalls behoben: ein Deadlock in dev_rebuild und ein Import-Fehler nach Disk-Ersetzungen, der dazu führte, dass Pools nach einem Rebuild nicht sauber importiert werden konnten.

Für alle, die Block Cloning einsetzen – also Copy-on-Write-Klone von Datenblöcken ohne physische Datenduplizierung – gibt es einen Fix für Read-Corruption nach Block Cloning kombiniert mit Truncation. Das betrifft vor allem Backup-Workflows mit zfs send/receive und klonbasierte Snapshot-Szenarien. Schließlich wurden mehrere seltene Checksum-Fehler behoben, die nach normalen Rebuilds auftreten konnten. Seltene Fehler sind in Storage-Systemen mit langen Laufzeiten keine beruhigende Aussage – sie akkumulieren sich.

Linux-Kernel-Kompatibilität bis 7.0

OpenZFS 2.4.2 unterstützt laut den vorliegenden Berichten Linux-Kernel von 4.18 bis 7.0. Das ist der Teil des Release, der für Distributionen mit schnellem Kernel-Tempo direkt relevant wird. Ubuntu Server, Fedora und Arch Linux kommen regelmäßig mit neuen Kernel-Versionen, und ZFS-Out-of-Tree-Kernel-Module müssen mit jedem größeren Kernel-Sprung neu abgestimmt werden.

Die Änderungen betreffen konkret die FS_context-basierte Mount-API für neuere Kernel, Anpassungen am Mount-Option-Handling, Lease-Handler und ACL-bezogene Kernel-Änderungen sowie Block-Q-API-Änderungen. Das sind keine kosmetischen Fixes – es geht um fundamentale Schnittstellen zwischen ZFS-Modul und Kernel, die sich mit modernen Kerneln verschoben haben. Wer seinen Server auf Linux 6.x oder 7.0 betreibt und bisher noch auf OpenZFS 2.4.0 oder 2.4.1 saß, hat spürbare Kompatibilitätsrisiken im Modulbetrieb.

Für FreeBSD-Nutzer gilt: 2.4.2 unterstützt FreeBSD 13.3 und 14.0+. Wer Proxmox auf Debian-Basis betreibt, muss auf den Proxmox-eigenen Release-Zyklus warten, der ZFS-Updates über das eigene Repository einspielt. Das Gleiche gilt für Ubuntu Server mit dem zfs-dkms-Paket aus dem offiziellen Repository und für Debian Bookworm, dessen Backports-Zweig erfahrungsgemäß mit einigen Wochen Verzögerung folgt.

dRAID im Fokus: Warum gerade dieser RAID-Typ Fixes bekommt

Distributed RAID – kurz dRAID – ist gegenüber klassischem RAIDZ die modernere und bei großen Disk-Zahlen effizientere Variante. Der entscheidende Unterschied: Bei dRAID verteilt ZFS Parity und Spare-Kapazität gleichmäßig über alle Disks im Pool, was Rebuild-Zeiten bei Disk-Ausfällen erheblich verkürzt. In der Theorie. In der Praxis ist dRAID damit intern komplexer als RAIDZ, und genau in dieser Komplexität lagen die Bugs, die 2.4.2 behebt.

Das ist kein Zufall. dRAID wurde in OpenZFS 2.1 als stabile Funktion eingeführt und wird seitdem in jeder Version weiter gehärtet. Der Bug mit korrumpierten Daten nach Disk-Reset und der Deadlock in dev_rebuild sind Symptome eines Codes, der in bestimmten Race-Condition-Szenarien noch nicht vollständig abgesichert war. Solche Bugs zeigen sich oft erst unter Produktionslast – nicht im Lab-Test.

Meine Einschätzung: Wer dRAID produktiv einsetzt, sollte 2.4.2 nicht aufschieben. Die alternativen RAIDZ-Konfigurationen sind von diesen spezifischen Fixes nicht direkt betroffen, aber das heißt nicht, dass das Update für RAIDZ-Nutzer irrelevant ist – die Checksum-Fixes und Kernel-Kompatibilitäts-Änderungen gelten pool-übergreifend.

Snapshot- und Mount-Handling: Stabilisierung im Alltag

Snapshot-basierte Workflows sind das Herzstück vieler Self-Hosting-Setups – automatische nächtliche Snapshots, inkrementelle Replikation via zfs send, klonbasierte Rollbacks. OpenZFS 2.4.2 bringt Verbesserungen bei Snapshot-Automount und Concurrent zfs recv, also bei parallelen Empfangsvorgängen. In Setups, die Replikation auf mehrere Ziele gleichzeitig betreiben – etwa ein lokaler Mirror plus Off-Site-Backup – konnte das bisher zu Hänge- oder Fehlerzuständen führen.

Die Leak-Fixes rund um Mount- und Snapshot-Handling klingen nach Haushalts-Fixes, sind aber in lang laufenden Systemen relevant. Memory-Leaks akkumulieren sich über Wochen und Monate; auf einem Server, der selten neu gestartet wird, sind das keine theoretischen Probleme. Dass diese Fixes explizit im Release auftauchen, deutet darauf hin, dass sie in realen Deployments aufgefallen sind.

Zusätzlich verbessert 2.4.2 die Unterstützung für POSIX_FADV_DONTNEED. Das ist ein Hinweismechanismus an das Betriebssystem, bestimmte Cache-Seiten freizugeben – relevant für Backup-Software und große sequenzielle Lesevorgänge, die sonst den ARC (den ZFS-eigenen Adaptive Replacement Cache) mit Daten fluten, die danach nicht mehr gebraucht werden.

Update-Pfade: Was für Ubuntu, Debian, Fedora und Proxmox gilt

Auf Ubuntu Server 24.04 LTS kommt ZFS über das zfsutils-linux-Paket und zfs-dkms aus dem Universe-Repository. Canonical aktualisiert diese Pakete mit Verzögerung, typischerweise nach einer Evaluierungsphase. Wer auf dem aktuellsten OpenZFS-Stand bleiben will, muss entweder auf die offizielle PPA von OpenZFS auf GitHub zurückgreifen oder auf den Canonical-Paket-Zyklus warten.

Auf Debian Bookworm landet OpenZFS über Backports. Der Zeitverzug zwischen Upstream-Release und Paket-Verfügbarkeit in Bookworm-Backports ist erfahrungsgemäß mehrere Wochen. Wer dringend auf 2.4.2 angewiesen ist, kann das Paket manuell bauen – mit den üblichen Risiken für die Paketintegrität des Systems.

Proxmox VE bündelt ZFS fest mit dem eigenen Kernel und Paket-Ökosystem. Proxmox-Updates zu neuen OpenZFS-Versionen erscheinen im pve-no-subscription– oder pve-enterprise-Repository, aber nicht synchron mit Upstream. Wer Proxmox produktiv betreibt, sollte die offizielle Proxmox-Changeliste im Blick behalten, bevor er ZFS-Module manuell aktualisiert – Inkompatibilitäten zwischen ZFS-Modul und dem Proxmox-Kernel sind bekannte Risikoquellen.

Fedora liefert ZFS nicht im offiziellen Repository aus, weil die CDDL-Lizenz von OpenZFS inkompatibel mit der GPL des Linux-Kernels ist – ein bekannter und seit Jahren ungelöster Lizenzkonflikt. ZFS auf Fedora läuft über das ZFS on Linux-Installationsverfahren mit DKMS, was die Kernel-Kompatibilitäts-Fixes in 2.4.2 besonders relevant macht, weil Fedora häufig sehr aktuelle Kernel-Versionen mitbringt.

Praktische Vorbereitungsschritte vor dem Update

Wer 2.4.2 in einem produktiven System einspielt, sollte vor dem Update einen definierten Ablauf einhalten – unabhängig davon, ob der Pool RAIDZ oder dRAID nutzt. Erstens: Pool-Status prüfen mit zpool status. Ein degradierter Pool, der noch auf einen Rebuild wartet, ist kein guter Ausgangspunkt für ein ZFS-Modul-Update. Zweitens: Aktuellen Scrub abschließen. Ein laufender Scrub sollte vor dem Update beendet sein, um ausstehende Checksum-Korrekturen sauber abzuschließen.

Drittens empfiehlt sich ein Export aller Pools, bevor das ZFS-Modul ausgetauscht wird – auch wenn das in vielen Setups nicht praktikabel ist, weil Pools aktiv gemountet sind. Als Minimum sollte sichergestellt sein, dass ausstehende Schreibvorgänge abgeschlossen sind, bevor das DKMS-Modul über den Paketmanager aktualisiert und der Kernel neu geladen wird.

Viertens: Kernel-Modul-Version nach dem Update verifizieren. Mit modinfo zfs | grep version lässt sich prüfen, ob das neue Modul tatsächlich geladen wurde oder noch das alte im Speicher aktiv ist. Ein Neustart ist in den meisten Fällen der sicherste Weg, um sicherzustellen, dass Kernel und ZFS-Modul aus demselben Build stammen.

Für Proxmox-Nutzer gilt ein zusätzlicher Hinweis: Wer ZFS manuell aus Upstream baut, anstatt auf den Proxmox-Paket-Zyklus zu warten, riskiert, dass spätere Proxmox-Kernel-Updates das manuell installierte Modul wieder überschreiben oder in einen inkonsistenten Zustand bringen. Eine klare Dokumentation des Update-Pfads ist hier kein Luxus, sondern Pflicht.

Parallelzweig 2.3.7: Wann der Wechsel auf 2.4 lohnt

Neben 2.4.2 wurde mit OpenZFS 2.3.7 ein paralleles Wartungsupdate für den älteren Zweig veröffentlicht. Das ist ein explizites Signal des Projekts: Wer noch nicht auf 2.4 gewechselt ist, muss das jetzt nicht erzwingen. Die 2.3er-Linie wird weiterhin gepflegt.

Die Frage, ob ein Wechsel von 2.3.x auf 2.4.x sinnvoll ist, hängt von zwei Faktoren ab. Erstens: Nutzen Sie Funktionen, die 2.4 neu eingeführt oder signifikant verbessert hat? Zweitens: Wie hoch ist der Aufwand für einen Pool-Upgrade? Manche Pool-Feature-Flags, die mit neueren ZFS-Versionen aktiviert werden können, sind nicht rückwärtskompatibel. Ein Pool, der einmal auf neue Feature-Flags hochgesetzt wurde, lässt sich nicht mehr mit älterem OpenZFS öffnen. Das ist kein Bug, sondern Design – und es ist der Grund, warum konservative Storage-Admins Versions-Upgrades nicht leichtfertig anstoßen.

Die Empfehlung lautet pragmatisch: Wer auf 2.4.x ist, sollte auf 2.4.2 aktualisieren, weil die Fixes direkte Stabilitätsrelevanz haben. Wer auf 2.3.x ist und kein dRAID, Block Cloning oder neue Kernel-API-Abhängigkeiten hat, kann auf 2.3.7 gehen und den Sprung auf 2.4 in Ruhe planen.

Langfristige Monitoring-Strategie für ZFS-Pools

Ein Update auf 2.4.2 löst die unmittelbaren Bugs – ersetzt aber keine systematische Überwachung aktiver Pools. Gerade in Setups, die dRAID oder Block Cloning nutzen, sollte ein automatisierter Scrub-Rhythmus fest eingeplant sein. Üblich sind wöchentliche Scrubs für Pools mit hoher Schreiblast, monatliche für primär leseintensive Archive. Das Ergebnis jedes Scrubs lässt sich mit zpool events und zpool history nachvollziehen und in Monitoring-Systeme wie Zabbix, Prometheus oder einfache Cron-basierte Mailbenachrichtigungen integrieren.

Darüber hinaus ist die Kernel-Versionsverwaltung auf ZFS-Systemen ein oft unterschätzter Aspekt. Wer automatische Kernel-Updates aktiviert hat, ohne einen entsprechenden DKMS-Rebuild-Mechanismus zu konfigurieren, riskiert, dass nach einem Kernel-Sprung kein kompatibles ZFS-Modul geladen wird und der Pool beim nächsten Boot nicht importiert werden kann. Gerade angesichts der erweiterten Kernel-Kompatibilität, die das Scheduler-Design neuer Linux-Kernel-Versionen beeinflusst, lohnt sich ein gezielter Blick darauf, wie DKMS im eigenen System konfiguriert ist und ob der Rebuild-Hook nach Kernel-Updates tatsächlich zuverlässig ausgeführt wird.

Wer mehrere ZFS-Server verwaltet, sollte außerdem einen einheitlichen Update-Kanal definieren – entweder konsequent Distributions-Pakete oder konsequent Upstream-Builds, aber keine Mischung beider Quellen im selben System. Unterschiedliche ZFS-Versionen auf Source- und Destination-System bei zfs send/receive-Replikation sind in der Regel unproblematisch, aber neuere Feature-Flags auf dem sendenden System können zu Importfehlern auf einem älteren Empfängersystem führen.

Was das Release für die OpenZFS-Gesamtrichtung sagt

OpenZFS 2.4.2 ist in meinen Augen ein Zeichen, dass das Projekt aktuell auf Stabilisierung statt Feature-Expansion setzt. Die großen Funktionsschritte – dRAID in 2.1, Block Cloning in 2.2, native Verschlüsselung, Zstd-Komprimierung – sind eingeführt, werden aber weiter gehärtet. Das ist keine Schwäche des Projekts, sondern das Verhalten eines reifenden Storage-Substrats, das produktiv auf Systemen mit langen Laufzeiten und hohen Integritätsanforderungen läuft.

Die Kernel-Kompatibilität bis Linux 7.0 zeigt außerdem, dass OpenZFS den schnellen Kernel-Entwicklungszyklus der letzten Jahre – mit API-Änderungen an Mount-Infrastruktur, Block-Layer und Dateisystem-Schnittstellen – mithalten muss. Das ist strukturell aufwendig für ein Out-of-Tree-Modul, das nicht Teil des offiziellen Linux-Kernel-Baums ist. Die CDDL-Lizenz bleibt das zentrale Hindernis für eine echte Kernel-Integration, und das wird sich mittelfristig nicht ändern. Wer ZFS auf Linux betreibt, kauft damit bewusst die Wartungsarbeit eines externen Moduls ein – mit all den Vorteilen des ZFS-Datenmodells und der realen Inkompatibilitätsmöglichkeit nach jedem größeren Kernel-Sprung.

Der Blick auf die OpenZFS-Projektseite zeigt eine aktive Community mit klaren Release-Zyklen – für ein Storage-Filesystem ohne kommerzielle Backing-Organisation bemerkenswert stabil. Die parallele Pflege von 2.3.x und 2.4.x ist dabei kein Zeichen von Unentschlossenheit, sondern von Pragmatismus gegenüber einer heterogenen Nutzerschaft.

Was bleibt

OpenZFS 2.4.2 ist kein Release, das Schlagzeilen mit neuen Features macht. Es ist ein Release, das verhindert, dass Daten in spezifischen Rebuild-, Klon- und dRAID-Szenarien unbemerkt korrumpiert werden. Für ein Filesystem, das sich auf das Versprechen von Datenintegrität und automatischer Selbstheilung stützt, sind genau das die Releases, die zählen.

Die eigentliche Frage ist nicht, ob Sie 2.4.2 einspielen sollten – das sollten Sie, wenn Sie auf dem 2.4-Zweig sind. Die Frage ist, wie Ihr Update-Prozess für ZFS-Pakete aussieht: automatisch über Distribution, manuell aus Upstream, oder gar nicht? Wer das noch nicht klar geregelt hat und produktive Pools betreibt, sollte das jetzt klären – bevor der nächste Kernel-Sprung die Kompatibilitätsfrage stellt, ohne dass ein Wartungsfenster geplant ist.