Die Woche: Ext4-Bug: Kein Grund zur Panik!
Große Aufregung um einen letztlich irrelevanten Fehler: Ein Bug in Ext4 hat sich als Folge der Kombination mehrerer exotischer Optionen herausgestellt. Betroffen ist offenbar nur ein einziger Linux-User.
- Dr. Oliver Diedrich
Hohe Wellen hat vergangene Woche der Fehlerbericht des Users "Nix" geschlagen, der Daten auf seinem Ext4-Dateisystem verloren hatte. Zwar stellte sich schnell heraus, dass es sich um einen Einzelfall handelt, bei dem mehrere kritische Optionen zusammenkamen, und der Bug ist inzwischen gefixt; aber die öffentliche Suche nach der Ursache hat der Angelegenheit eine Menge Publicity verschafft und für einige Aufregung in der Linux-Welt gesorgt. Daher wollen wir hier versuchen, die Dinge ein wenig ein einen Kontext zu stellen.
Ext4 ist derzeit das Standard-Dateisystem für Linux, es gilt als robust, ausgereift und gut getestet (siehe dazu auch den Hintergrundartikel Das Linux-Dateisystem Ext4). Robust, weil das mit dem Vorgänger Ext3 eingeführte Journal selbst bei einem Stromausfall während einer Schreiboperation die Konsistenz des Dateisystems garantiert; ausgereift, weil Ext4 am Ende einer langen Entwicklung steht, die vor fast 20 Jahren mit Ext2 begann; und gut getestet, weil seit damals die allermeisten Linux-Systeme auf Ext2, Ext3 oder Ext4 installiert wurden – ein massenhafter Einsatz in der Praxis ist nun mal der beste Test.
Lazy Unmount
Normalerweise kann man unter Linux ein gemountetes Dateisystem nicht aushängen, solange noch ein Prozess auf eine irgendeine Datei auf dem Dateisystem zugreift – und sei es nur eine Shell, deren Working Directory auf dem Dateisystem liegt. Umount meldet dann "device is busy". Normalerweise findet man in so einem Fall mit fuser oder lsof heraus, welcher Prozess das Aushängen blockiert, und beendet ihn.
Nun können Linux-Prozesse aber so hängen bleiben, dass sie sich nicht mehr abschießen lassen; oder das Aushängen wird durch sonst einen Fehler (etwa ein nicht antwortender NFS-Server) blockiert, der sich nicht so einfach beheben lässt. Für solche Fälle gibt es die Mount-Option -l, die ein "lazy unmount" anfordert: Das Dateisystem wird sofort ausgehängt; das System versucht, das dadurch angerichtete Chaos (Datei-Handles ohne Datei etc.) im Nachhinein zu reparieren. Dass mount -l eine Option für besondere Fälle ist und mit Datenverlust einher gegen kann, sollte eigentlich klar sein.
Ist das jetzt, nach dem Ext4-Bug, alles Makulatur? Nein, natürlich nicht – ganz im Gegenteil.
Jeder Programm-Code von der Komplexität, die ein modernes, leistungsfähiges Dateisystem erfordert, enthält Fehler – der Ext4-Code besteht aus rund 40.000 Zeilen Quelltext. Dass eine Kombination aus mehreren Mount-Optionen (nobarrier, journal_checksum und journal_async_commit), die alle standardmäßig nicht verwendet werden, und dazu ein "lazy unmount" (siehe Kasten) nötig sind, um einen Fehler zu triggern: Das spricht nicht gegen, sondern für die Robustheit von Ext4 und für die Qualität der Tests, denen der Code unterzogen wurde. Dass sich die Ext4-Entwickler auch in so einer Situation sofort auf die Suche nach dem Fehler machen, belegt die Ausgereiftheit von Ext4; sonst hätten die Entwickler nämlich Wichtigeres zu tun als einem esoterischen Bug nachzugehen, der nur bei einem einzigen Anwender aufgetreten ist. Selbst Ext4-Chefentwickler Theodore Ts'o konnte den Bug auf seinen Systemen bislang nicht provozieren.
Man darf daher getrost davon ausgehen, dass Daten auf Ext4 sicher sind – sicherer jedenfalls als auf allen anderen Linux-Dateisystemen: Die Entwicklung von ReiserFS/Reiser4 ist eingeschlafen, das Next Generation Filesystem Btrfs noch nicht wirklich im Produktivbetrieb angekommen und das ursprünglich für das SGI-Unix Irix entwickelte XFS in einer Nische steckengeblieben. Und auch bei anderen Betriebssystemen gibt es Dateisystemfehler – sie werden nur nicht so öffentlich diskutiert.
Dass die Ext4-Entwickler trotzdem Konsequenzen aus dem Ext4-Bug ziehen wollen, ist begrüßenswert. Allerdings hätte man das schon längst tun können: Schon vor einem Jahr warnte Ted Ts'o auf der LinuxCon Europe in Prag, dass bei manchen Mount-Optionen Probleme mit Ext4 auftreten könnten, da diese wenig getestet seien. Diesen Hinweis hätte man sich auch in der man page zu mount gewünscht. Immerhin: Jetzt sollen diese Optionen, von denen einige überhaupt nur für Entwickler gedacht waren, aus dem Produktiv-Code verschwinden oder bei Verwendung zumindest eine Warnung ausgeben. Auch eine Art von Bug-Fix ... (odi) (odi)
