Holpriger Start: OpenZFS 2.4.0 mit schneller Verschlüsselung – und Problemen

Noch im Dezember veröffentlichten die Entwickler von OpenZFS die Version 2.4.0 ihres selbstheilenden Dateisystems, das aus dem vor über 20 Jahren für Solaris entwickelten ZFS von Sun Microsystems hervorgegangen ist. Explizit werden Linux-Kernel 4.18 bis 6.18 sowie FreeBSD 14, das aktuelle Production-Release 15 und die in rund zwei Jahren kommende Version 16 („-current“) unterstützt.

Ein Patch von Ameer Hamza führt Standard-Quotas für Benutzer, Gruppen und Projekte in OpenZFS ein – inklusive Objekt-Quotas – und sorgt so für eine konsistente Begrenzung, auch wenn keine individuellen Limits gesetzt sind. Dazu werden Kernel- und Userspace-Werkzeuge (zfs {user|group|project}space) unter FreeBSD und Linux angepasst, so dass Standard-Quotas angezeigt werden, falls keine individuellen Quotas konfiguriert wurden.

Eine Änderung von Alexander Motin erweitert die ZIL-Allokation so, dass bei fehlendem SLOG auch Special-vdevs (typischerweise SSDs) für ZIL-Blöcke genutzt werden, um unlogische Zuordnungen mit höheren Latenzen auf HDDs zu vermeiden. Damit können HDD-Pools mit einem schnellen Special-vdev synchrone Workloads besser bedienen. Das geht dann ohne zusätzliches SLOG und erlaubt in gewissen Grenzen den Verschleiß von SSDs zu minimieren.

Joel Low hat bereits im Februar letzten Jahres Code von Googles BoringSSL nach OpenZFS portiert, was angeblich eine bis zu 80 Prozent schnellere Verschlüsselung bringen soll. Dazu verwendeten die Entwickler bei Google eine Vector-AES-optimierte AES-GCM-Implementation (Galois/Counter Mode), bei der auf AMD Zen3-CPUs das schnelle AVX2 statt AVX512/AVX10 eingesetzt wird.

Drei neue Befehle

Wer OpenZFS 2.4.0 einsetzt, sollte sich mit drei neuen Befehlen vertraut machen: „zfs rewrite -P“ versucht beim erneuten Schreiben von Blöcken die Birth Time beizubehalten und so Zeit und Ressourcen einzusparen, da sich die eigentlichen Daten ja nicht ändern. Mit „zpool scrub -S -E“ kann das Scrubbing auf bestimmte Zeiträume (basierend auf Transaction Groups / TXG) begrenzt werden – im Commit [ werden aber einige Probleme gemeldet. Mit „zpool prefetch -t brt“ schließlich sollen die Metadaten der BRT (Block Reference Table) vorab in den ARC (Adaptive Replacement Cache) eingelesen werden, um Block Cloning und das Freigeben von Blöcken zu beschleunigen (dazu unten mehr).

Die Mehrheit der Commits kommen von Rob Norris (229 Commits) und Alexander Motin (119 Commits), beide arbeiten für das auf FreeBSD, ZFS und ARM spezialisierte Unternehmen Klara. Acht Entwickler haben Commits im zweistelligen Bereich, der überwiegende Teil beschränkt sich auf genau einen Commit.

Ohne Cache schneller schreiben und Ärger mit den „Gang Blocks“

Während obige Neuerungen aus einzelnen Commits bestehen, bestehen vier Bereiche des neuen OpenZFS 2.4.0 aus einer ganzen Reihe von zusammengefassten Detailverbesserungen: Uncached I/O, Gang Blocks, Deduplication und Block Cloning. Alexander Motin arbeitet an der Optimierung von Uncached I/O-Operationen, die von der Performance her zwischen dem schnellen Direct I/O (mit Beschränkungen wie page alignment) und dem regulären Cached I/O liegen. Scheidet Direct I/O in bestimmten Szenarien aus, soll es einen Fallback auf Uncached I/O statt wie bisher auf das noch langsamere Cached I/O geben.

Mehrere Fixes sollen den Einsatz von „Gang Blocks“ verbessern. Gang Blocks sind eine Art Notfallmechanismus von ZFS, der greift, wenn für einen großen Daten- oder Metadatenblock kein zusammenhängender freier Speicherplatz mehr verfügbar ist. In diesem Fall zerlegt ZFS den Block in mehrere kleinere physische Blöcke und speichert zusätzlich mindestens zwei redundante Gang Block Header, die auf diese Teilblöcke verweisen, sodass der Block logisch weiterhin als Einheit behandelt werden kann. Eine der Verbesserungen ist, die Größe der Gang Block Header von fixen 512 Byte auf eine beliebige dynamische Größe zu verändern.

Die ins Gigantische wachsende Datensammelwut von Konzernen und Regierungen macht Optimierungen bei der Deduplizierung von OpenZFS besonders notwendig. Alleine acht Commits sollen OpenZFS 2.4.0 dabei helfen, Speicherplatz zu sparen.

Sorgenkind Block Cloning gefixt – oder doch nicht?

Wie Alexander Motin klarstellt, wurde bei der ursprünglichen Implementation des Block Clonings ein struktureller Fehler gemacht, der die „BRT ZAP Entries“ betrifft, nun aber korrigiert ist. Block-Cloning erlaubt es, Dateien oder Teile davon zu kopieren, indem nur Referenzen zu bestehenden Blöcken angelegt werden, statt Daten zu duplizieren. Das spart Platz und Zeit, weil die Daten nicht erneut geschrieben werden müssen.

Die Block Reference Table (BRT) ist ein neues Metadaten-Objekt in OpenZFS (eingeführt in 2.2), das Block-Cloning beziehungsweise „Reflinks“ unterstützt. OpenZFS speichert die BRT-Einträge in einem ZAP-Objekt. ZAP (ZFS Attribute Processor) ist eine flexible On-Disk-Struktur für Schlüssel/Wert-Daten, beispielsweise Verzeichnisse, Eigenschaften oder eben Referenztabellen. Weitere Fixes sollen das Block Cloning von OpenZFS stabiler und weniger fehleranfällig machen. Fehlerhaftes Block Cloning sorgte bereits bei OpenZFS 2.2.0 für Datenverluste.

Ist manche NVMe-Hardware nicht OpenZFS-kompatibel?

Neben den Problemen durch Block Cloning scheint OpenZFS auch mit NVMe-Pools ein wenig auf Kriegsfuß zu stehen. Neben Kommentaren bei OpenZFS-Postings oder Foreneinträgen gibt es auch lange Diskussionen, beispielsweise auf Github. In fast allen diesen Diskussionen wird auf Probleme insbesondere mit NVMe-Laufwerken hingewiesen, SATA- und SAS-HDDs/SSDs scheinen weniger betroffen zu sein. Ob der Fehler dabei im OpenZFS zu suchen ist, oder ob es sich um Hardware-Probleme handelt, ist nicht immer klar und sorgt für teilweise hitzige Auseinandersetzungen.

Eine weitere Möglichkeit wäre, dass manche NVMe-Hardware von OpenZFS unter hoher Last einfach überfordert ist. Wenn diese Hardware mit anderen Dateisystemen oder sogar älteren ZFS-Varianten funktioniert, und wenn auch das aktuelle OpenZFS auf anderen Systemen fast überall sauber läuft – ist dann die spezielle Kombination das Problem? Vielleicht ist auch ein genauer Blick auf die eingesetzte NVMe-Controller-Hardware und dessen Firmware sinnvoll? Vor allem Consumer-Hardware wird oft hart an der Spezifikationsgrenze gebaut und könnte dann unter härteren Bedingungen von OpenZFS zu Fehlern neigen. Das Problem sollte genau analysiert werden, da vor allem leistungsfähige OpenZFS-Installationen gerne auf NVMe-Hardware aufbauen.

OpenZFS ist verfügbar für GNU/Linux, FreeBSD, NetBSD, macOS, OpenSolaris, Illumos und OpenIndiana. Der Quellcode von OpenZFS 2.4.0 liegt zusammen mit einer ausführlichen Liste aller Neuerungen und Änderungen auf Githuv.

(axk)