Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten

Kernel-Log: Beutelteufel vorübergehend Linux-Maskottchen, Ext4-Problem erhitzt die Gemüter

Seite 2: Datenverlust unter Ext4, Grafik, Kernel-Log-Staccato

Inhaltsverzeichnis

Datenverlust unter Ext4

Vergangene Woche sorgte eine Meldung über mögliche Datenverluste mit Ext4 für Aufregung und hitzige Diskussionen: Ein Anwender verlor bei einem Systemcrash unmittelbar nach dem Start von KDE 4 auf einer Alpha-Version von Ubuntu 9.04 mit Ext4 eine Menge Daten – nach dem Reboot hatten fast alle Dateien, die während des letzten Starts geschrieben worden waren, eine Größe von 0 Byte und waren leer. Mit Ext3 sei ihm so etwas nie passiert, beklagte er.

Was war passiert? Wenn Anwendungen eine bestehende Datei mit neuen oder geänderten Daten überschreiben wollen (etwa eine Konfigurationsdatei, nachdem der User eine Einstellung geändert hat), legen sie für die neuen Daten häufig zunächst eine temporäre Datei an und benennen die anschließend mit dem Systemcall rename() um. Die Logik dahinter: Wenn beim Schreiben etwas schief geht, etwa der Rechner abstürzt oder der Strom ausfällt, bleibt zumindest die alte Version der Datei erhalten.

Dabei passieren zwei Dinge. Zum einen ändern sich Metadaten im Dateisystem: Für die neue Datei wird ein Inode angelegt, der die Daten referenziert, und ein neuer Verzeichniseintrag erzeugt, der auf den neuen Inode zeigt; beim rename() wird der Verzeichniseintrag der alten Datei dann so geändert, dass er auf den neuen Inode zeigt. Zum andern werden die Daten selbst geschrieben: Dazu muss das Dateisystem zunächst ausreichend viele Datenblöcke auf der Platte allozieren und dann die Daten in diese Blöcke schreiben.

Ext3 wie Ext4 schreiben alle Änderungen an den Metadaten zunächst in ihr Journal; auch nach dem rename() hat sich daher im Dateisystem selbst zunächst nichts geändert. Wenn jetzt der Strom ausfällt, existiert die neue Datei im Dateisystem noch nicht: Der Verzeichniseintrag der alten Datei zeigt auf den alten Inode und damit auf die alten Daten, die geänderten Metadaten im Journal sind noch nicht gültig. Dazu ist nämlich noch ein "Commit" der Änderungen im Journal nötig – erst dann überträgt das Dateisystem nach einiger Zeit (oder beim nächsten Reboot nach einem Crash) die geänderten Metadaten ins Dateisystem.

Dabei gibt es jedoch einen entscheidenden Unterschied zwischen Ext3 und Ext4. Ext3 (mit der Standard-Mount-Option "data=ordered") führt mit den Commit der Metadaten im Journal erst aus, wenn die Daten der neuen Datei tatsächlich auf die Platte geschrieben sind (was bis zu fünf Sekunden dauern kann, während denen die Daten noch im Cache zwischengespeichert sind). Das soll verhindern, dass nach einem Systemcrash in einer neu angelegten Datei alte Daten auftauchen, wenn die allozierten Datenblöcke zuvor von einer inzwischen gelöschten Datei belegt waren und noch nicht mit den neuen Daten beschrieben sind. Die Datei enthält nach einem Systemabsturz also entweder die alten oder die neuen Daten – je nachdem, ob der Crash vor oder nach dem Commit erfolgt.

Ext4 hingegen führt einen weiteren Mechanismus ein: delayed block allocation. Es kann nach dem Schließen einer Datei bis zu einer Minute dauern, bis tatsächlich Datenblöcke auf der Platte alloziert werden. Die delayed block allocation erlaubt dem Dateisystem eine bessere Optimierung von Schreibprozessen – allerdings um den Preis, dass die Metadaten einer neu angelegten Datei bis zu der verzögerten Allozierung eine Größe von 0 Byte und keine belegten Datenblöcke ausweisen. Wenn das System in dieser Zeitspanne abstürzt, kann die rename()-Operation im Journal bereits committed sein, obwohl die neue Datei noch keine Daten enthält. Ergebnis: Nach einem Crash ist die Datei leer, alte und neue Daten sind verloren.

Ext4-Entwickler Ted Ts'o betont in seiner Antwort auf den Bug-Report, dass sich Ext4 genau so verhält, wie es der POSIX-Standard für Dateioperationen fordert. Zudem zeigen andere Dateisysteme wie XFS das gleiche Verhalten; das "sicherere" Verhalten von Ext3 ist lediglich ein unbeabsichtigter Nebeneffekt. Das Problem sind für Ts'o die Anwendungsentwickler, die das gutmütige Verhalten von Ext3 als Standard nehmen. Sein Rat: Wenn eine Anwendung sicher sein will, dass Daten tatsächlich auf Platte geschrieben werden, muss sie vor dem Schließen der Datei die Funktion fsync() aufrufen.

Trotzdem hat er als Workaround sehr schnell Patches für Ext4 geschrieben, die die rename()-Situation (und eine zweite Vorgehensweise, bei der mit ftruncate() gearbeitet wird) erkennen und dort für ein Verhalten wie bei Ext3 sorgen. Mittlerweile hat Ted Ts'o aber auch für eine "richtige" Lösung gesorgt: Die neue Ext4-Mount-Option "alloc_on_commit" führt für Ext4 ein Analog zu "data=ordered" ein – Metadaten im Journal werden erst committed, nachdem die Blöcke alloziert und die Daten geschrieben sind. Die Änderung dürfte allerdings frühestens mit dem Kernel 2.6.30 kommen. (odi/heise open)

AMD-Mitarbeiter Alex Deucher hat die Version 6.12.0 der kurz meist "ati" genannten Treiberpakets xf86-video-ati freigegeben. Der dort enthaltene Treiber "radeon" soll zusammen mit einem aktuellem DRM (Direct Rendering Manager) nun die Beschleunigungstechniken EXA und Xv (Xvideo) bei den R6xx- und R7xx-GPUs unterstützen, die auf Radeon-Grafikhardware der Serien 2000, 3000 und 4000 arbeiten. Laut der Freigabe-Mail soll der Treiber nun zudem das Drehen des Bildes auf eben diesen GPUs beherrschen sowie die Ausgabe über Display-Port ermöglichen; laut den Informationen im X.org-Wiki geht das allerdings nur mit neueren Radeon-GPUs und nicht mit allen DP-Wiedergabegeräten.

Die Entwickler des Intel-Grafiktreibers arbeiten derweil auf den nächsten größeren Meilenstein hin und haben die ersten beiden Vorabversion der Treiber-Serie 2.7 veröffentlicht (1, 2). Fedora-Entwickler Will Woods erläutert derweil in seinem Blog, warum glxgears seiner Meinung nach kein guter Benchmark ist –Tester von Fedora-11-Vorabversionen hatte zuvor größere Einbrüche bei den Bildraten durch KMS und DRI2 ausgemacht. (thl/heise open)

Kernel-Log-Staccato

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich auch in den vorangegangen Ausgaben des Kernel-Logs auf heise open:

Ältere Kernel-Logs finden sich über das Archiv oder die Suchfunktion von heise open. (thl/heise open) (thl)

Spiele

nach oben
Alle Angebote
Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten