Development Site

Bogdan Gribincea hat einen Fehler in Ubuntu 9.04 berichtet, bei dem Dateien eines als Ext4 angelegten Dateisystems verloren gehen.

Hintergrund ist die Verzögerung beim Schreiben auf die Festplatte, wodurch nach einem Absturz Daten verloren gehen können, die zu diesem Zeitpunkt in Bearbeitung waren. Hintergrund dieser Verzögerung sind Bestrebungen, die Schreibvorgänge auf die Festplatten zu minimieren um beim Einsatz von Notebooks Strom zu sparen und die Datenkanäle für andere Daten freizuhalten. Daneben beugt dieses Verhalten auch der Fragmentierung der Daten auf dem Datenträger vor. Effektiv bedeutet dies, dass Daten, die eine Anwendung speichert, tatsächlich erst einige Sekunden (bis zu 60 Sekunden bei Ext4) auf den Datenträger geschrieben werden und solange nur im Hauptspeicher vorliegen. Diese Technik ("Delayed Allocation" oder "Allocate-on-flush") ist allerdings nicht wirklich neu und wird von vielen Dateisystemen genutzt, darunter auch zfs und xfs.

Ext4 wird zwar seit Kernel 2.6.28 als stabil bezeichnet, aber Erfahrungen wurden im breiten Einsatz bislang kaum gemacht, da die gängigen Distributionen - mit Ausnahme von ArchLinux - noch keinen Kernel 2.6.28 oder neuer mitliefern. Insofern ist das erste Auftauchen von derlei Fehlern in Jaunty, der momentanen Entwicklerversion von Ubuntu, zwar bedauerlich, es hilft jedoch dabei, solche Mängel beseitigen zu können. Umso mehr, da die hohe Anzahl an verloren gegangenen Daten nach einem Absturz laut Kernel-Entwickler Ted T'so eher unerwartet und wohl darauf zurückzuführen ist, dass bestimmte Anwendungen, wie zum Beispiel KDE oder GNOME, eine große Anzahl an Dateien gleichzeitig beschreiben, die dann nach einem Crash einfach leer erscheinen. Somit liegt der Fehler wohl eher in der Interaktion von verschiedenen Bestandteilen einer Linux-Distribution und nicht nur an einem einzigen Dateisystem.

Abhilfe sollen einige Patches schaffen, die jedoch wohl erst in den Kernel 2.6.30 aufgenommen werden:

• ext4: add EXT4_IOC_ALLOC_DA_BLKS ioctl
• ext4: Automatically allocate delay allocated blocks on close
• ext4: Automatically allocate delay allocated blocks on rename

Bis dorthin steht für vorsichtige Gemüter ja noch Ext3 zur Verfügung. Ansonsten müssten sich die Entwickler von Applikationen in nächster Zeit Gedanken machen, wie sie Schreibvorgänge auf Speichermedien so gestalten können, damit gespeicherte Daten auch wirklich auf dem Datenträger landen. T'so bietet hier auch gleich Vorschläge wie die Nutzung der in vielen Programmiersprachen vorhandenen Funktion fsync() oder fdatasync() sowie das Speichern in eine neue Datei und deren daran anschließende Umbenennung unter Beibehaltung der Vorgängerversion (Kommentar von Ted T'so).

Quelle: Launchpad Bugtracker, Heise online