Aktuelles OpenZFS kann Daten zerstören

FreeBSD stand kurz vor dem Release, als die Entwickler Fehler beim Speichern von Dateien feststellten, die offenbar im Zusammenhang mit der noch frischen Version 2.2.0 des Dateiystems OpenZFS standen. Nach intensiver Suche vermuteten sie das Problem in der neuen Block-Cloning-Optimierung von OpenZFS.

Auch Terin Stocks aus dem Team von Gentoo Linux stellte Fehler bei der Datenspeicherung fest, als er den Go-Compiler auf einem Gentoo Linux mit OpenZFS installierte. Nach dem Erzeugen der Binaries über die Paketverwaltung Portage enthielten viele der erzeugten Dateien Nullen und/oder Datenmüll. Besonders ärgerlich ist, dass der ZFS-Ingegritätsprüfer scrub diese Fehler nicht erkennt.

OpenZFS 2.2.0 wurde am 13. Oktober freigegeben. Block Cloning ist eines der neuen Features. Dabei werden "kopierte" Blöcke einer Datei nicht wirklich kopiert, sondern nur zusätzlich referenziert. Erst bei einer Änderung an den originalen oder den kopierten Daten wird tatsächlich ein zweiter physischer Datenblock erzeugt. Der cp-Befehl von GNU/Linux verwendet diese Funktion bereits.

Das FreeBSD-Team deaktivierte also für FreeBSD 14 das Block Cloning, womit das Problem vorerst gelöst zu sein schien. Dieselbe Notfallmaßnahme wurde auch bei OpenZFS 2.2.1 oder beim gerade freigegeben Proxmox Virtual Environment 8.1 und dem Proxmox Backup Server 3.1 vorgenommen, die ebenfalls OpenZFS als für ihre Storage-Bereiche benutzen.

Fehler tiefer als vermutet

Der eigentliche Fehler scheint jedoch nicht zwangsläufig in der Block Cloning-Funktion selbst zu liegen. Viele Entwickler vermuten mittlerweile, dass das Problem bereits zuvor auch in älteren Versionen von OpenZFS vorhanden war, aus irgendeinem Grund durch das Block Cloning"jedoch massiv zu Tage tritt. Ed Maste von der FreeBSD-Foundation warnt daher alle OpenZFS-Nutzer, das Block Cloning bis auf weiteres auf keinen Fall zu aktivieren. Für FreeBSD 14.0 und 13.2 kann man als Workaround "Enable forcing txg sync to find holes" abschalten:

root@freebsd14:~ # echo vfs.zfs.dmu_offset_next_sync=0 >> /etc/sysctl.conf
root@freebsd14:~ # sysctl vfs.zfs.dmu_offset_next_sync=0

Ob darüber hinaus das Block Cloning überhaupt aktiv ist, kann man unter FreeBSD 14 leicht überprüfen:

root@freebsd14:~ # sysctl -d vfs.zfs.bclone_enabled
vfs.zfs.bclone_enabled: Enable block cloning
root@freebsd14:~ # sysctl vfs.zfs.bclone_enabled
vfs.zfs.bclone_enabled: 0

Ältere Versionen von OpenZFS melden hier einen Fehler (sysctl: unknown oid 'vfs.zfs.bclone_enabled') und scheinen zunächst einmal sicher. "Scheinen", weil sich die Entwickler wie oben erwähnt zur Zeit noch nicht hundertprozentig sicher sind, dass der Fehler einzig und alleine in der neuen Block Cloning-Funktion liegt. Man vermutet, dass durch das Block Cloning ein tiefer im OpenZFS-System steckender Fehler auftritt.

Ursachenforschung

Bronek Kozicki versucht die Ursache genauer zu beschreiben: Wird eine Datei(-änderung) asynchron geschrieben und ist noch nicht abgeschlossen könnte ein weiterer Prozess beim Versuch, diese Daten zu lesen, Nullen statt der geänderten Daten erhalten. Diese Nullen schreibt der Prozess dann – für OpenZFS und scrub vollkommen korrekt – auf den Datenträger. Damit werden falsche Daten auf korrekte Weise ins OpenZFS-Dateisystem geschrieben. Die Korrektheit der Daten kann man nur sicherstellen, wenn man sie über Prüfsummen oder durch Abgleich mit früheren Backups überprüft.

Tony Hutter hat ein kleines Skript auf Github veröffentlicht, mit dem man eigene OpenZFS-Dateisysteme überprüfen kann. Dabei werden massiv Dateien erzeugt, kopiert und überprüft. Das Skript sollte lediglich als Werkzeug betrachtet werden, eine fehleranfällige OpenZFS-Version zu identifizieren. Treten keine Fehler auf, bedeutet das nicht, dass der Fehler nicht doch tiefer im System schlummert.

(ulw)