Journaling Dateisysteme

Ein großer Nachteil der traditionellen Unix-Dateisysteme ist die interne Verwaltung von Dateisysteminformationen. Der Superblock eines Dateisystems wird beim Mounten des Dateisystems in den Arbeitsspeicher geladen und alle Veränderungen des Superblocks werden dort vorgenommen. Die eigentlichen Veränderungen am Dateisystem (Anlegen, Verändern oder Löschen von Dateien) werden aber tatsächlich minütlich auf der Platte vorgenommen. Erst beim Abhängen des Dateisystems (in der Regel beim Herunterfahren) wird der im Speicher liegende Superblock physikalisch auf die Platte geschrieben.

Dieser Mechanismus spart zwar Zeit, weil Zugriffe auf den Arbeitsspeicher wesentlich schneller erledigt werden können, als Zugriffe auf die Platte, aber er birgt große Risiken. Wenn ein solches Dateisystem nicht korrekt abgehängt wird, etwa bei einem Systemabsturz oder Stromausfall, dann kann der aktuelle Superblock nicht mehr auf die Platte geschrieben werden. Der Zustand des Dateisystems ist dann inkonsistent, das bedeutet, daß der Superblock nicht mehr die tatsächliche aktuelle Situation des Dateisystems beschreibt, sondern die, die das Dateisystem beim vorletzten Mounten aufwies.

Linux reagiert auf diese Inkonsistenz mit einem erzwungenen Dateisystemcheck beim Booten, wenn das System merkt, daß eine Platte nicht korrekt abgehängt wurde. Dieser Systemchek kann - je nach Partitionsgröße - sehr lange dauern und im schlimmsten Fall einen manuellen Eingriff erfordert. Das bedeutet, daß ein abgestürzter Server lange nicht mehr zur Verfügung steht und eventuell sogar nicht mehr automatisch wieder hochfährt.

Um dieses Problem zu lösen, wurden moderne Dateisysteme mit einem neuen Mechanismus ausgestattet, dem Journaling. Dabei wird jede Transaktion zwischen dem System und der Platte in einem Journal mitprotokolliert, so daß nach einem Absturz in sehr kurzer Zeit wieder ein konsistenter Zustand hergestellt werden kann. Das bedeutet nicht, daß alle Daten wiederhergestellt werden können, die durch den Absturz womöglich verlorengingen, sondern nur, daß es zu keiner Diskrepanz zwischen Superblock und Dateisystem kommen kann.

Dazu wird beim Systemstart - falls es zu einem Absturz gekommen war - das Journal gelesen und die darin enthaltenen Transaktionen werden quasi Stück für Stück rückgängig gemacht, bis es wieder zu einem konsistenten Zustand kommt. Dieser Vorgang kann wesentlich schneller ausgeführt werden, als ein Dateisystemcheck eines herkömmlichen Dateisystems, weil nicht die ganze Platte überprüft werden muß. Die Dauer ist auch nicht abhängig von der Größe der Partition.

Linux bietet heute mehrere Dateisystemtypen an, die das Journaling beherrschen. Bemerkenswert sind dabei die folgenden:

Ext3fs

Ext3fs ist nicht wie der Name vermuten ließe ein echter Nachfolger von Ext2fs, dem Standard-Dateisystem unter Linux. Ext3fs ist vielmehr eine Erweiterung von Ext2fs, da sich am Dateisystem so gut wie nichts entscheidendes zum "Vorgänger" verändert hat. Die Erweiterung beschränkt sich - etwas übertrieben gesagt - im wesentlichen auf das Hinzufügen einer Datei - dem Logfile. Das Ziel bei der Entwicklung von Ext3fs war es mit minimalen Änderungen eine komplette Lösung zu finden, die das Journaling unterstützt. Hierfür wurde dann eine Kopie des Ext2fs-Quellcodes gemacht und eine textuelle Ersetzung durchgeführt mit der "ext2" durch "ext3" ersetzt wurde. Hinzugefügt wurde dann eine vom Dateisystem selbst völlig unabhängige Schicht die das Journaling übernimmt. Das Dateisystem selber hat nichts mit dem Journaling zu tun. Die einzige Änderung die das System hinter sich hat ist, dass es jede Aktion die Schreibend auf die Festplatte zugreift in eine Transaktion packt. D.h. es wird der Journaling-Schicht mitgeteilt, welche Blöcke innerhalb einer Transaktion geändert werden sollen. Den Rest übernimmt dann die neue Journaling-Schicht.

ReiserFS

Beim Dateisystem des Hans Reiser werden im Journal alle Metadatenänderungen protokolliert, die mehr als einen Block betreffen. Bei einem Systemabsturz ist also lediglich sichergestellt, dass das System sehr schnell wieder in einen konsistenten zustand gesetzt wird. Datenverluste kann es weiterhin geben, da ja "nur" die Metadaten im Journal gesichert werden.

Die Datenstruktur wird hier in einem B*-Baum gespeichert. In den Blättern werden vier verschiedene Arten von Datensätzen gespeichert:

direkte Datensätze: Alle kleinen Dateien (< 1 Block) werden direkt im Baum gespeichert. (Eine 10 Zeichen große Datei landet bei Ext2fs in einem Block von z.B. 1024 Bytes) Hierdurch wird Plattenplatz und ein zusätzlicher Plattenzugriff gespart
indirekte Datensätze: Hier werden Zeiger auf größere Dateien, die dann außerhalb des Baumes liegen, gespeichert
Verzeichnisse: Enthält die einzelnen Einträge eines Verzeichnisses
stat data: Was Ext2fs in Inodes speichert wird hier direkt im Baum gespeichert.

Jeder Datensatz besitzt einen eindeutigen Schlüssel (Hashfunktion), der zum Sortieren und Wiederfinden benutzt wird. Durch die Verwaltung des Baumes (ausbalancieren beim Hinzufügen bzw. Löschen von Einträgen) nimmt das Speichern etwas mehr Rechenzeit in Anspruch als der einfache Mechanismus beim ext2.

XFS

XFS ist eine Portierung des Dateisystems von IRIX, das bereits seit langem auf den bekannten Grafik-Workstations und Servern von Silicon-Graphics läuft. Die Version 1.0 erschien am 1.Mai 2001. Da es in diesem Bereich besonders auf Sicherheit und Geschwindigkeit ankommt ist XFS besonders für große Dateien ausgelegt. Wenn man bedenkt, dass Dateien bis zu 9.000 PByte groß sein können (zur Information die Reihenfolge: Kilo-, Mega-, Giga-, Terra-, Peta-, Exa-Byte).

Die technischen Details füllen ganze Seiten. Zu erwähnen wäre z.B. dass mit dem plattformübergreifenden xfsdump/xfsrestore sogar Dumps von IRIX nach Linux transferiert werden können.