Das Problem ist nicht unbedingt das Dateisystem, sondern das alte Drama mit lügender Konsumerhardware. Wobei das über Jahre deutlich besser geworden ist. Um etwas auszuholen muss die Software davon ausgehen, dass das System jederzeit crashen kann. Durch Programmfehler und damit Absturz, durch gekippte Bits aufgrund von einem Alpha-Teilchen zur falschen Zeit am falschen Ort, durch Stromausfall und so weiter. Daher muss der Zustand der Daten auf dem Speichermedium jederzeit konsistent sein. Dem steht allerdings im Weg, dass sich zwischen der Daten schreibenden Anwendung und dem Speichermedium mehrere Caches (Dateisystemcache des Kernels, eventuell ein Cache des Controllers, interner Cache der Festplatte oder der SSD, bei SSDs noch Zuordnungstabellen, etc.) und andere Magie (als Beispiel NCQ bei Festplatten, was ATA- und SCSI-Befehle umordnen kann) befinden.
Der einfachste Weg Konsistenz sicher zu stellen ist synchrones Schreiben. Das ist das, was OpenBSD mit FFS macht. Einfach gesagt schickt man jeder Schreiboperation, die Metadaten verändert, ein Cache Flush hinterher. Damit ergibt sich ein minimales Zeitfenster zwischen Schreiben der Metadaten und dem Cache Flush, in dem das Dateisystem inkonsistent ist. Das lässt noch weiter minimieren, indem man erst Daten und das Metadaten schreibt. Ein fsck kann nach dem Crash halb geschriebene Metadaten wegräumen. Das funktioniert an sich gut, hat allerdings den Nachteil, dass es die Caches aushebelt. Das tut ziemlich weh, je langsamer das Speichermedium ist, umso mehr. Daher wollte man eigentlich immer vom Synchronen schreiben weg.
Linux experimentierte in den 90ern mit asynchronem Schreiben, also keine Rücksicht auf Caches zu nehmen. extfs und ext2fs (algorithmisch letztendlich vereinfachte Implementierungen von Kirk McKusiks Paper zu FFS) waren die beiden Dateisysteme, die es taten. Man versucht halbwegs geordnet in recht simple Datenstrukturen zu schreiben und hofft, es nach dem Crash durch fsck aufräumen zu können. Das funktionierte nicht, bei ext2fs hieß ein Crash in den 90ern das Backup rauszuholen zu müssen.
Danach ging man bei Linux zu Journaling über und bei FreeBSD zu Soft Updates. Da die Mechaniken zum großen Teil im VFS, also dem Abstraktionslayer zwischen Dateisystem und Kernel implementiert werden müssen, war das eine Richtungsentscheidung. Nachdem Linux mit XFS die Strukturen für Journaling geschaffen hatte, war es der Weg, den alle darauffolgenden Dateisysteme wie ext3, ext4 und eine ganze Reihe exotischerer Vertreter gingen. Diese Strukturen sind unter anderem Filter, die Daten von Metadaten trennen und Write Barriers, die Sicherstellen, dass Reihenfolgen eingehalten werden. Die Idee hinter Journaling ist, dass man erst eine Undo-Redo-Log ins Journal schreibt. Dann die Daten und zum Schluss die Metadaten. Nach einem Crash kann man anhand der Undo-Redo-Log, also dem Journal, nachvollziehen, was hätte gemacht werden sollen. Das wird mit dem Ist-Zustand abgeglichen und daraus ein konsistenter Zustand erstellt.
Soft Updates sind konzeptionell ähnlich, kommen aber ohne Undo-Redo-Log aus. Man filtert den Datenstrom durch, schreibt erst die Daten aus, sammelt parallel dazu die Metadaten und schreibt diese am Ende in einer Operation synchron aus. Damit sind die Metadaten immer synchron, geschriebene aber nicht in den Metadaten abgebildete Daten sind nach einem Crash verloren.
Etwas später, Mitte der 2000er, kam das ZFS mit einem ganz anderen Ansatz. Es ist Copy on Write, überschreibt also niemals Daten. Stattdessen wird in Transaktionen gedacht. Es wird immer ein neuer Datensatz geschrieben und dieser nach dem Schreiben aktuell gesetzt. Sind die Daten geschrieben, aber noch nicht aktuell gesetzt, sind sie nach einem Crash verloren. Sobald sie aktuell gesetzt sind, sind sie sicher ausgeschrieben. Sollte, aus welchen Gründen auch immer, die letzte Transaktion auf dem Speichermedium inkonsistent sein, kann man in der Transaktionshistorie zurückgehen und einen älteren Zustand wiederherstellen.
Um zum Ausgangsproblem zurückzukommen, sind alle diese Methoden darauf angewiesen, dass die Hardware die Wahrheit sagt. Also das ein Cache Flush Dinge auch wirklich auf allen Ebenen der Kette ausschreibt und nicht nur "Ja klar hab ich ausgeschrieben, trust me Bro!" behauptet. Denn in dem Moment geht die Software davon aus, dass ausgeschrieben wurde, was die Hardware nicht hat. Früher war das echt die Pest. Ich und viele andere hatten Generationen von Konsumerhardware, die gerne mal aus dem Grund Dateisysteme zerschredderte. Linux machte sich viel Mühe drum herum zu werkeln, die BSDs sahen es eher nicht so ein. Irgendwann, vor allem durch Druck von Microsoft, wurd es besser. Im Moment sind vor allem einige SSDs das Problem, die ihre Zuordnungstabellen im Cache halten und um ein paar Cent zu sparen keinen Stützkondensator haben, sodass sie Falle eines Stromausfalls oder harten Ausschaltens Daten verlieren.
Lange Rede, kurzer Sinn: Lügende Hardware wird auf jedem Betriebssystem mit jedem Dateisystem Ärger machen. Es fragt sich nur wie viel. Ob die eigene Hardware lügt, weiß man im Zweifel erst hinterher. Dafür gibt es Backups, die man immer, völlig unabhängig von Hardware und Software, dem Betriebssystem, dem Dateisystem und der Mondphase haben sollte.
Mit Überlegungen, welches Betriebsystem oder Dateisystem da besser ist, würde ich gar nicht erst anfangen. Vor allem führt das immer zu Fragen um Pest und Cholera. Als Beispiel ist die ganze FFS- und UFS-Familie recht simplel aufgebaut. Es sind lineare Strukturen, man kann einfach ausrechnen, wo die Daten liegen und sie auslesen. Tools wie ffs2recov machen das automatisch, mit Debuggern wie fsdb kann man es manuell machen. Es ist daher fast unmöglich in letzter Konsequenz auf FFS oder UFS Daten zu verlieren. Allerdings haben die Dateisysteme keinen Mechanismus die Konsistenz der Daten zu garantieren. ZFS kann das wiederum, aber erkauft es sich mit deutlich höherer Komplexität. Da heißt kaputt meist auch tatsächlich kaputt. Lässt ein Pool sich nicht mehr öffnen, sind die Daten weg. Was darf es also sein? Wiederherstellbare Daten ohne Garantie, dass die wiederhergestellten Daten auch wirklich konsistent sind oder doch lieber garantiert konsistente Daten, die im Zweifel verloren sind? Ist beides blöd. Also einfach Backups machen und nicht allzu viele Gedanken an die Robustheit des Dateisystems verschwenden.
