Kernel-Entwickler streiten über Ext3 und Ext4
Eine Diskussion über das Verhalten von Ext4, Nutzdaten erst nach den Metadaten auf die Platte zuschreiben, hat den Linux-Vater auf den Plan gerufen.
Etliche namhafte Kernel-Entwickler, darunter Linus Torvalds, Ted Ts'o, Alan Cox und Ingo Molnar, haben sich auf der Kernel-Mailing-Liste über den Sinn und Unsinn von Journaling und Delayed Allocation bei Ext3 und Ext4 gestritten.
Auslöser für die Diskussion war eine Antwort von Jesper Krogh auf Linus' Ankündigung von Kernel 2.6.29, in der er massive Verzögerungen beim Wegschreiben des Dateisystem-Caches auf Ext3-Dateisystemen trotz schnellem RAID-Verbund bei Rechnern mit viel RAM beschrieb.
Ingo Molnar identifizierte die maximale Dirty Ratio, also der Anteil des Speichers, der auf die Festplatten geschrieben werden muss, als einen wesentlichen Teil des Problems: Die Dirty Ration liege noch immer bei fünf Prozent des RAMs, was in der Vergangenheit auf Systemen mit vielleicht 1 GByte Hauptspeicher nur wenige Megabytes ausmachte.
Auf heutigen Servern mit 32 GByte RAM und acht oder 16 Prozessoren, die parallel Dirty Pages produzieren, könnte die zu schreibende Datenmenge zwischen zwei Synchronisationen des Dateisystems auf bis zu 1,6 GByte anschwellen. Da jedoch die Datentransferraten der Festplatten nicht in gleichem Maße gewachsen sind wie der verfügbare RAM, dauere die Synchronisation nun unter ungünstigen Umständen länger als früher – wobei Ted Ts'o darauf hinwies, dass die Synchronisation bei Ext3 ja alle fünf Sekunden erfolge und daher in der Regel weniger Daten geschrieben würden.
Diesen Hinweis auf die 5-Sekunden-Intervalle griff Linus Torvalds auf und bezeichnete die Standard-Vorgehensweise von ext4, wo reguläre Daten standardmäßig nur noch alle 120 Sekunden aus dem Cache weggeschrieben werden, während dies bei den Metadaten sehr viel früher passiere, als Irrsinn. Bei Ext3 sei es mit der Mount-Option "data=writeback" das gleiche, nur habe man es dort wenigstens nicht zum Standard erhoben (normalerweise wird Ext3 mit "data=ordered" gemountet, sodass die Änderungen an den Metadaten erst nach dem Schreiben der Nutzdaten gültig werden).
Diese Vorgehenswise sei aber hirnrissig und er könne nicht verstehen, wie Dateisystem-Programmierer die Methode "sauberes Dateisystem bei Datenverlust", wie sie typisch bei Writeback-Caches ist, akzeptieren können.
Den Vorschlag von Ted Ts'o, auf Single-User-Maschinen zur Vermeidung der Synchronisationsprobleme einfach auf Ext4 zu wechseln, kommentierte Torvalds damit, dass Ext4 doch standardmäßig mit diesem "beschissenen, irrsinnigen" Writeback-Cache arbeiten würde. Klar, der würde viele Probleme umgehen, weil die Nutzdaten damit nicht mehr in den kritischen Journal-Schreibzugriffen auftauchen, aber jeder, der meine, dies sei eine Lösung, sei schlicht inkompetent. Da könne man genauso gut zu Ext2 zurückkehren – wenn wie bei Ext4 Nutzdaten erst lange nach den Metadaten auf der Platte landen, würde man zwangsläufig in all die Probleme rennen, wenn der Rechner jemals abstürzt.
Ts'o konterte, durch das verzögerte Schreiben von Nutzdaten ließe sich halt gut die Performance des Dateisystems steigern und diese Methode sei auch vom Posix-Standard gedeckt. Bei Ext2 bräuchte man nach einem Absturz stets eine langwierige Überprüfung per fsck, um nicht vollständig geschriebene Daten ausfindig zu machen, während das bei Ext4 nicht mehr nötig sei, weil hier spätestens nach dem Abarbeiten des Journals immer ein konsistenter Zustand gewährleistet ist – auch wenn die Nutzdaten es nicht mehr auf die Platte geschafft hätten. Außerdem könne man die Häufigkeit, mit der Nutzdaten aus dem Cache auf Platte geschrieben werden, individuell anpassen und zur Not auch ganz darauf verzichten. Letztlich könne der Systemadministrator die Parameter je nach vorhandener Hardware auf das führ ihn optimale Verhalten optimieren.
Für Torvalds ist die Frage, ob ein fsck-Aufruf nach einem Absturz nötig ist, völlig zweitranging – wenn ein Dateisystem durch einen Absturz beschädigt ist und Daten nicht geschrieben werden konnten, dann ist das Dateisystem eben nicht mehr einwandfrei. Wobei er einen schleichenden Datenverlust, den man mangels fsck gar nicht mehr gemeldet bekomme, für schlimmer halte, als wenn man wie bei Ext2 nach einem Absturz mit der Nase darauf gestoßen wird, dass mit dem Dateisystem etwas nicht stimmen könnte. Er verstehe nicht, wie Dateisystem-Entwickler denken könnten, fsck sei das eigentliche Problem. Das sei offenkundig falsch.
Der Punkt sei, dass es bei zunehmender Verzögerung zwischen dem Schreiben der Metadaten und dem Schreiben der Nutzdaten immer wahrscheinlicher wird, dass eine Datei beschädigt oder unvollständig ist, als wenn man beide Daten unmittelbar nacheinander speichert. Während man, wenn man die Nutzdaten zuerst speichere, letztlich keine Beschädigungen des Dateisystems erleben würde.
Dies sei der Grund, warum er den idiotischen Writeback-Cache von Ext3 abgrundtief hasse. Es würde alles genau falsch herum machen – Nutzdaten erst nach den Metadaten schreiben, die auf diese Nutzdaten verweisen. Wer auch immer diese Lösung ersonnen habe, sei ein Irrer gewesen, da gäbe es gar keinen Zweifel. (mid)
