© Amy Walters, 123RF.com

Mit ihren Journalen müssten moderne Dateisysteme – so die reine Lehre – immun sein gegen Inkonsistenzen. Dass dem nicht so ist, zeigen die Allgegenwart von Fsck und ein Blick in die Filesystem-Historie.

Der nachhaltigste Grund für die Existenz des Fsck ist ein geschichtlicher: das Ur-Design des Unix-Filesystems (FS). Es gibt fünf Datenstrukturen im FS: Verzeichniseinträge, Inodes, Datenblöcke, Inode-Bitmaps und Block-Bitmaps. Verzeichniseinträge enthalten einen Dateinamen und eine Inode-Nummer. Inodes speichern den Benutzer, die Gruppe, Berechtigungen und andere Metadaten, vor allem aber Verweise auf die Datenblöcke. Datenblöcke wiederum enthalten schließlich den Datei-Inhalt. Verzeichnisse sind schlicht Dateien, deren Inhalt aus Verzeichniseinträgen besteht.

Bei nahezu allen Operationen auf einem Dateisystem ändern sich mehrere dieser Strukturen gleichzeitig. Zum Erzeugen einer neuen Datei zum Beispiel markiert das Betriebssystem im einfachsten Fall einen unbenutzten Inode in der Bitmap als benutzt, schreibt ihn selbst und speichert schließlich einen Verzeichniseintrag, der auf den Inode verweist (Abbildung 1). Wenn nun der Computer abstürzt, der Strom ausfällt oder ein ungeschicktes Knie gegen den übergroßen Stromschalter drückt und dabei der Computer den schlechten Geschmack besitzt, dies inmitten der eben beschriebenen Schreiboperationen zu tun, bleibt ein inkonsistentes Dateisystem zurück.

Abbildung 1: Im Inode, hier bei Ext 2, verweisen bis zu zwölf Einträge auf je einen Cluster, in dem der Inhalt der Datei gespeichert ist. Reichen die zwölf Cluster nicht aus, zeigt ein Inode-Eintrag auf einen Cluster, der die Verweise zu den eigentlichen Datenclustern enthält.

Verheerende Folgen

Der beste Fall von Inkonsistenz ist der Verlust von Speicherplatz. So ist etwa der Inode als benutzt markiert, aber noch nicht geschrieben oder zumindest nicht in einem Verzeichnis verlinkt. Schlimmer kommt es, wenn die Operationen in einer anderen Reihenfolge ausgeführt werden. Dabei kann ein Verzeichniseintrag entstehen, der auf einen ungeschriebenen Inode verweist. Dessen alter Inhalt verweist vielleicht auf eine gelöschte Datei eines anderen Nutzers, etwa auf die Lösungen der kommenden Matheklausur. Die Sache gerät schnell zum Sicherheitsproblem, das nach Vermeidung ruft.

Der erste Ansatz der Dateisystem-Entwickler war, alle Teiloperationen streng in der beschriebenen Reihenfolge auszuführen, sodass im Fehlerfall nur Speicherplatz verloren geht, aber keine Strukturen auf undefinierten Speicher verweisen. Leider zwingt das die Festplatte sehr viele quasi-zufällige Zugriffe auszuführen. Der einhergehende Performance-Einbruch war für die Benutzer wenig erquicklich.

Asynchron betriebene Dateisysteme dagegen lassen Linux keine große Wahl, es muss zwingend einen Dateisystem-Check ausführen, wann immer der Rechner abgestürzt ist oder sein könnte. Die Dateisysteme selbst arbeiten dafür deutlich schneller. Der Benutzer muss nur streng darauf achten, den Rechner sauber herunterzufahren. Jeden hastigen Druck auf den Stromschalter bestraft Fsck mit einer Kaffeepause beim nächsten Booten.

Journale und Softupdates

Die nächste Verbesserung brachten Journaling-Filesysteme und Softupdates. Ein journalisierendes Dateisystem folgt dem Prinzip, die zusammenhängenden Veränderungen im Voraus anzukündigen. Diese Ankündigung landet im Journal. Danach kann es alle angekündigten Teiloperationen in beliebiger Reihenfolge ausführen ([1], [2]). Sollte der Rechner zwischendurch abstürzen, vollführt der Rechner ein Journal-Replay.

Hierbei absolviert ein Dateisystem wahlweise die angekündigten Veränderungen ein weiteres Mal (Roll Forward) oder nimmt sie komplett zurück (Roll Back). In beiden Fällen entsteht wieder ein konsistentes Dateisystem – und spart den Fsck-Lauf nach jedem Absturz.

Der Nachteil des Journals ist, dass es die Daten effektiv doppelt schreibt – einmal in das Journal und ein zweites Mal in das eigentliche Dateisystem. Der Berkeley-FFS-Erfinder und Usenix-Ex-Präsident Kirk McKusick und andere [3], haben mit Softupdates eine etwas effizientere Alternative entwickelt. Im Prinzip führten sie das alte synchrone Verhalten wieder ein, das frühere Dateisystem-Entwickler ja unbedingt vermeiden wollten.

Der Trick von Softupdates besteht darin, dass jede Operation in sich synchron ist, sie aber viele Operationen parallel ausführt. Leider steigt zugleich die Struktur-Komplexität dramatisch. Der geneigte Dateisystementwickler hört spätestens auf Seite 10 des Referenzpapiers auf zu lesen, da ihm der Kopf brummt.

Damit bleiben Softupdates eine Spezialität der BSD-Derivate. Gerüchten zufolge wollte Sun in besseren Zeiten Softupdates in die eigenen Dateisysteme einbauen. Dies scheiterte, da Kirk McKusick damals nicht verfügbar war und sich niemand sonst zutraute, Softupdates in produktive Systeme einzuführen.

Fsck aus später Einsicht

Mit Journaling in Dateisystemen – glaubten Benutzer wie Entwickler – entfällt die Daseinsberechtigung von Fsck. Folgerichtig besaß kaum ein Journaling-Filesystem bei seiner Einführung einen Fsck. Wie so oft erwies sich die Praxis als Kriterium für die Wahrheit: Unter Entwicklern kursieren genug Geschichten, etwa die von jenem Kunden, der die ersten 30 MByte einer Partition überschrieben hatte, weshalb ihm die Dateisystem-Entwickler nach Monaten doch ein Fsck nachreichten. In der BSD-Welt mit Softupdate behielt Fsck ohnehin einen festen Platz, da die Benutzer gerne ihren verlorenen Speicherplatz wieder zurückwollen.

Selbst wenn es oft zur Unzeit zuschlägt (siehe Kasten “Wann Fsck loslegt”): Vier Gründe sprechen für die (Weiter)-Existenz von Dateisystem-Checks: Neben Benutzern mit einer Unterdosis Koffein (Montagmorgensyndrom) gibt es noch defekte oder schlechte Hardware, die hin und wieder Daten korrumpiert. Und natürlich ist da noch dieses leidige Thema mit nicht behobenen Bugs im Dateisystem-Code selbst. Es bleiben also noch genug Möglichkeiten, seine Daten zu verlieren. Rette sie, wer kann! (jk)