OpenZFS 2.4: Was Anwender vom Update wirklich merken

OpenZFS 2.4 ist das größte Feature-Release seit OpenZFS 2.0 vor fünf Jahren — und das erste, das vier kommerziell relevante Neuerungen in einer Version bündelt: AnyRaid, Block Reference Table (BRT), gereifte dRAID-Implementierung und stabilere RAIDZ-Expansion. Erstmals voll integriert ist 2.4 in TrueNAS 26 “Halfmoon”, nachfolgende Linux-Distributionen werden in den kommenden Monaten ziehen.

Dieser Artikel beantwortet die für Anwender wichtigste Frage: Was merke ich im Alltag wirklich? Wir lassen die meisten Roadmap-Details weg und konzentrieren uns auf die vier Punkte, die echte Workload-Unterschiede machen.

Die vier großen Punkte im Überblick

Feature	Was es löst	Wer profitiert spürbar
AnyRaid	Verschnitt bei gemischten Plattengrößen	Homelabs, schrittweise Migration auf größere Disks
BRT (Block Reference Table)	Lange Klone-Operationen, doppelte Belegung	VM-Cloning, DB-Refresh, Build-Pipelines
dRAID-Reife	Lange Resilver-Zeiten bei großen Pools	Pools ab 24+ Disks, Backup-Pools, Object-Targets
RAIDZ-Expansion	Statische VDEV-Größe	Wachsende Mittelstands-NAS, Homelabs

Dazu kommen viele kleinere Verbesserungen (ARC-Speicher-Verwaltung, Snapshot-Replikations-Performance, Encryption-Edge-Cases, Crash-Recovery), die für jeden ZFS-Anwender hilfreich sind, aber nicht den Charakter “Feature-Sprung” haben.

AnyRaid: Pools aus gemischten Disks

AnyRaid ist die am meisten wahrnehmbare Neuerung für KMU- und Homelab-Anwender. Bisher galt in ZFS die strenge Regel: in einem VDEV (z.B. RAIDZ2 oder Mirror) wird nur die Kapazität der kleinsten Disk genutzt. Wer ein Mirror aus einer 8-TB- und einer 10-TB-Disk baute, hatte 8 TB nutzbar — die 2 TB Verschnitt waren weg.

AnyRaid bricht das auf. Pools können jetzt aus Disks unterschiedlicher Größe gebaut werden, ohne dass die größeren Disks ihren Mehr-Platz verlieren. Wer einen Pool schrittweise von 4 TB auf 12 TB Disks migriert, gewinnt sofort.

Detaillierte technische Einordnung haben wir im separaten Artikel ZFS AnyRaid: Endlich Pools aus gemischten Plattengrößen. Hier nur die Anwender-Sicht:

Profitieren spürbar:

• Homelabs mit heterogenem Disk-Bestand
• KMU-NAS, die über Jahre gewachsen sind und Disks aus mehreren Beschaffungs-Runden enthalten
• Resilver mit größerer Disk: bisher musste die Resilver-Disk exakt gleich groß sein, AnyRaid lockert das

Profitieren wenig:

• All-Flash-Pools mit homogenem SSD-Bestand
• Enterprise-Setups, in denen Disks ohnehin chargenweise beschafft werden
• Production-Pools mit strenger Hardware-Standardisierung

BRT (Block Reference Table)

Block Reference Table ist eine ZFS-interne Verwaltungsstruktur, die Reference-Counts auf Blöcke ohne Copy-on-Write-Overhead verwaltet. Praktisch heißt das: ZFS kann Klone (z.B. zfs clone oder cp --reflink) schneller und mit weniger Speicherverbrauch durchführen.

In OpenZFS 2.3 war BRT als Tech-Preview vorhanden, aber mit Edge-Cases — in 2.4 ist es produktionsreif und Default für viele Klon-Operationen.

Workloads, die spürbar profitieren:

# Datenbank-Refresh: VM-Disk aus Snapshot klonen
zfs clone tank/db@nightly tank/db-test
# Bisher: schneller Sync auf Metadaten-Ebene, aber bei großen Klonen langsam
# Mit BRT: instant, ohne nennenswerten Block-Sync

• VM-Cloning in Proxmox: qm clone auf ZFS-Backend wird deutlich schneller, besonders bei großen Templates
• CI/CD-Pipelines, die Test-Datenbanken aus Snapshots ableiten
• Container-Workflows mit reflink-Volumes (z.B. Docker-Storage-Driver auf ZFS)
• Backup-Workflows, die häufig Dataset-Klone für Snapshot-Verifikation erzeugen

Weniger spürbar:

• Klassische File-Server-Workloads ohne aktives Klonen
• Read-Heavy-Workloads (Streaming, Archiv)
• Setups, die Snapshots nur zum Backup nutzen, aber keine Klone

Quelle: OpenZFS 2.4 Release Notes (github.com/openzfs).

dRAID — endlich erwachsen

dRAID (Distributed RAID) wurde mit OpenZFS 2.1 eingeführt, war aber lange ein “spezielles” Feature mit Edge-Cases im Resilver-Verhalten. Mit 2.4 ist dRAID produktionsreif für viele Anwendungsfälle.

Der Grundgedanke: anstatt jeden Spare als physische Reserve-Disk zu halten, verteilt dRAID Spare-Kapazität virtuell über alle Disks im VDEV. Bei einem Disk-Ausfall startet der Rebuild sofort und parallel auf vielen Disks gleichzeitig — was die effektive Resilver-Zeit dramatisch verkürzt.

Pool-Typ	Klassischer RAIDZ-Resilver (Erfahrungswert)	dRAID-Resilver bei vergleichbaren Disks
8× 18 TB HDD	24–48 Stunden	8–16 Stunden (laut OpenZFS-Doku, abhängig von Last)
24× 18 TB HDD	mehrere Tage	unter 24 Stunden bei sauberem Setup
60× 18 TB HDD	Bei klassischer Topologie problematisch	dRAID ist hier oft die einzige praktikable Option

Wichtige Einordnung: Diese Zahlen kommen aus der OpenZFS-Dokumentation und Conference-Talks der iX-Entwickler — wir haben keine eigenen kontrollierten Benchmarks. In der Praxis hängt der Resilver-Speed stark von Last während des Rebuilds, Pool-Auslastung und Disk-Performance ab.

Profitieren spürbar:

• Große Backup-Pools (PBS, TrueNAS-Replikations-Empfänger)
• Object-Storage-Targets (große HDD-Pools für Archive)
• Kapazitäts-Optimierte M-Serie/V-Serie-Pools bei TrueNAS

Eher nicht:

• Klassische 8–12-Disk-Pools im Mittelstand — dort ist RAIDZ2 weiter die richtige Wahl
• All-Flash-Pools — Resilver-Zeit ist sowieso kein Hauptthema
• Latenz-kritische Workloads — dRAID ist auf Capacity und Resilver optimiert, nicht auf minimale Random-Read-Latenz

RAIDZ-Expansion: stabil

RAIDZ-Expansion war bereits in 2.2 ein Feature-Highlight: einem bestehenden RAIDZ1/Z2/Z3-VDEV lassen sich nachträglich Disks hinzufügen, ohne den Pool neu anzulegen. In 2.3 wurde das stabilisiert, in 2.4 ist es jetzt routinemäßig einsetzbar.

# Beispiel: RAIDZ2-VDEV von 6 auf 8 Disks erweitern
zpool attach tank raidz2-0 /dev/sdh /dev/sdi

Was sich seit 2.3 noch verbessert hat:

• Schnellere Reflow-Phase (Daten werden parallel auf den neuen Disks rebalanced)
• Bessere Beobachtbarkeit: zpool status zeigt jetzt Reflow-Progress nutzbar
• Reduzierte Performance-Einbußen während der Expansion

Wichtig zu wissen:

• Parity-Level bleibt, aber die “Padding-Effizienz” für Daten, die vor der Expansion geschrieben wurden, ist suboptimal — das gilt weiterhin. Erst neu geschriebene Daten profitieren voll von der erweiterten Topologie.
• Wer Pools regelmäßig erweitert, sollte nach jeder Expansion einen Scrub laufen lassen und langfristig planen, kritische Datasets neu zu schreiben (z.B. via Replikation und Rückspielen).

Was nicht in 2.4 ist

Ehrliche Liste der Themen, die in der Community häufig gefragt werden, aber nicht in 2.4 enthalten sind:

• Online-RAIDZ-Topology-Change (z.B. von RAIDZ1 auf RAIDZ2 ohne Neuanlage) — weiterhin nicht möglich
• Dedup ohne speicherintensive DDT — Fast-Dedup-Verbesserungen sind in 2.3 gelandet, in 2.4 nur inkrementell
• Vollständig dynamische Pool-Reorganisation — Block-Pointer-Rewrite ist weiterhin nicht in Sicht
• Native S3-Tiering im Pool — kommt eher als Anwendungs-Schicht (z.B. via TrueNAS Cloud Sync oder PBS-S3-Targets)

Wer auf eines dieser Features wartet, sollte sich nicht von 2.4 ablenken lassen — der Roadmap-Stand ändert sich da nicht.

Wann sollte ich 2.4 produktiv einsetzen?

Pragmatische Antwort: wenn die Distribution / das Storage-OS es offiziell ausliefert. Konkret:

• TrueNAS 26 Enterprise (voraussichtlich Sommer/Frühherbst 2026): sicherer Weg, OpenZFS 2.4 produktiv zu nutzen
• Proxmox VE 9.x: ZFS-Version richtet sich nach Kernel-Modul-Auslieferung; in PVE 9.2 ist ZFS 2.4, in früheren 9.x noch 2.3
• Eigene Linux-Server mit OpenZFS direkt aus Source: nur, wenn Sie wirklich wissen, was Sie tun — Edge-Cases in der DKMS-Integration sind real
• Debian-/Ubuntu-Default-Pakete: hängen an der Distro-Major-Version, kommen mit Verzögerung

Wichtig: Ein Pool, der einmal Feature-Flags von OpenZFS 2.4 aktiviert hat (insbesondere AnyRaid oder neue BRT-Features), lässt sich nicht ohne weiteres auf einer älteren OpenZFS-Version importieren. Das ist Standard-ZFS-Verhalten, aber im Rollback-Szenario wichtig zu wissen.

Upgrade-Pfad in der Praxis

Wer einen bestehenden ZFS-Pool von 2.2/2.3 auf 2.4 hebt, sollte folgenden Pfad einhalten:

1. Pool-Status prüfen: zpool status -v, kein laufender Scrub/Resilver, keine CKSUM-Fehler
2. Komplettes Backup verifiziert vorhanden (siehe 3-2-1-Backup)
3. OS/Storage-OS-Update durchführen (TrueNAS 26, PVE 9.2 etc.)
4. Pool importiert sich automatisch mit den alten Feature-Flags
5. Optional: zpool upgrade <pool> aktiviert die neuen Features — bewusst entscheiden, ob Sie das wollen, denn danach kein Rollback auf alte ZFS-Version mehr
6. Scrub nach dem Upgrade laufen lassen — Erfolg verifizieren

In den meisten unserer Beratungen ist der Punkt 5 die Stelle, an der wir bewusst nicht sofort upgraden empfehlen — sondern erst, wenn der Bedarf an den neuen Features tatsächlich besteht. Pool-Stabilität geht vor “alle Feature-Flags an”.

DATAZONE-Empfehlung

OpenZFS 2.4 ist ein solides, breitflächiges Update. Drei Empfehlungen für unsere Mittelstands- und Storage-Kunden:

• Neue Installation: Sobald TrueNAS 26 Enterprise verfügbar ist, kann sie direkt auf 2.4 setzen. Vorteile (AnyRaid, BRT, dRAID-Reife) kommen kostenlos mit.
• Bestehende Pools: OS-Update einplanen, Feature-Flag-Upgrade bewusst nachgelagert entscheiden. Kein Druck.
• Hardware-Refresh: Wer ohnehin Disks erweitert oder migriert, plant das mit AnyRaid im Hinterkopf — das ist der natürliche Moment, gemischte Bestände sauber zusammenzubringen.

Für eine konkrete Planung — Pool-Upgrade, Hardware-Refresh, Migration zwischen TrueNAS-Generationen — bieten wir individuelle Beratung auf Basis der realen Pool-Statistik.

Quellen und weiterführende Artikel

• OpenZFS Release-Notes auf GitHub — offizielle Quelle für 2.4-Features
• OpenZFS-Dokumentation zu dRAID
• TrueNAS 26 Beta — Halfmoon-Release — Trägerplattform für OpenZFS 2.4
• ZFS AnyRaid: Endlich Pools aus gemischten Plattengrößen — die technische Tiefe zu AnyRaid
• ZFS RAID-Level erklärt — Grundlagen RAIDZ/dRAID
• ZFS SLOG und Special VDEV — komplementäre Tuning-Themen
• ZFS Komprimierung in der Praxis — weiterer Feature-Hebel