I-Nodes und Superblöcke

Ein Dateisystem speichert neben den eigentlichen Informationen auch zahlreiche Informationen über sich selbst. Zustand, Zugriffszeiten und Struktur sind wichtige Parameter, die Betriebssystem und Programme aus dem Dateisystem extrahieren und verarbeiten können.

Der Superblock

Zahlreiche Metainformationen sind im so genannten Superblock abgelegt. Da dieser Block für die Benutzung des Dateisystems extrem wichtig ist, werden automatisch Kopien von ihm an mehreren Stellen im Dateisystem angelegt.

Abbildung 1: Genereller Aufbau eines Superblocks

Sollte der erste Superblock einmal zerstört oder überschrieben sein, lässt sich das Dateisystem anhand einer Kopie restaurieren. Der Superblock liegt normalerweise an Position 0, eine Kopie an 8193 (oder 32768, je nach Erstellung).

Mittels e2fsck -b 8193 kann beispielsweise ein Dateisystem auf Fehler überprüft werden, selbst wenn der erste Superblock zerstört ist. Ist das betreffende System im schreibbaren Zustand gemountet, restauriert das Programm nach dem Check den ersten Superblock.

Im Superblock wird beispielsweise festgelegt, um welches Dateisystem es sich handelt und wie oft selbiges bereits ungeprüft gemountet wurde. Die wichtigsten Felder des Superblocks werden im Folgenden aufgeschlüsselt und sind in Abbildung 1 illustriert.

I-Node Count und Blocks Count enthalten die gesamte Anzahl der I-Nodes und Blöcke in diesem Dateisystem. Analog dazu bezeichnen Free Blocks und Free I-Nodes die Anzahl der noch freien Blöcke. Beim Erzeugen eines Dateisystems wird üblicherweise ein bestimmter Prozentsatz der Blöcke für den Administrator root reserviert. Die daraus resultierende Anzahl Blöcke wird im Feld Reserved-Blocks Count gespeichert.

Beim Booten sind die nächsten Felder in der Grafik von großem Interesse. Mount Count bezeichnet, wie oft dieses Dateisystem bereits ungeprüft gemountet wurde. Max Mount Count legt den maximalen Wert fest. Wird er überschritten, führt das Betriebssystem beim Booten auf jeden Fall den Dateisystem-Check durch – auch wenn das Dateisystem "sauber" ist (siehe Feld State) und ordentlich aus dem System entfernt wurde.

Ähnlich arbeiten die Felder lastcheck und checkinterval: Im ersten Feld ist das Datum des letzten Dateisystem-Checks gespeichert, und das zweite gibt an, wann spätestens wieder ein solcher Check durchgeführt wird. Beides sind Sicherheitseinstellungen, die dafür sorgen, dass Dateisysteme nach langem Gebrauch generalüberholt werden, damit potentielle Fehler (beispielsweise durch Bit-Kipper) korrigiert werden, vergleichbar mit der Jahresinspektion beim Auto.

Das letzte wichtige Feld ist mit First I-Node beschriftet. Dieses beinhaltet den I-Node, der das Root-Verzeichnis (/) in diesem Dateisystem enthält. Damit ist dieser I-Node der Einstiegspunkt in das Dateisystem, den man als Anwender des Linux-Systems sieht.

Dieser I-Node verweist auf einen Datenblock, in dem Verbindungen zwischen Namen und weiteren I-Nodes in diesem Verzeichnis beschrieben werden. Oftmals verweisen die Einträge auf I-Nodes, die selbst wieder ein Verzeichnis repräsentieren. Auf diese Weise lassen sich alle im Dateisystem enthaltenen Dateien nach und nach lokalisieren.

Journaling Filesystems

Das Dateisystem Ext2 (Second Extended Filesystem) arbeitet hervorragend und wurde speziell für Linux entwickelt. Festplatten wurden im Laufe der letzten Jahre immer größer konstruiert, und viele Anwender betreiben heute große Partitionen unter Linux. Dadurch hat sich ein Problem immer deutlicher heraus kristallisiert: Wird der Rechner einmal ausgeschaltet, ohne dass das Dateisystem sauber aus dem System entfernt wurde, dauert der Dateisystem-Check beim nächsten Booten extrem lange.

Das mag auf einem heimischen Rechner, der viele Musikdateien oder Filme speichert, vielleicht gerade noch akzeptabel sein, auf einem Produktions-Server ist es das jedoch nicht. Wird ein so genanntes Journal geschrieben, dann muss in einer solchen Situation im Prinzip nur das Journal abgearbeitet werden, um das Dateisystem zu restaurieren und wieder auf den aktuellen Stand zu bringen.

Abbildung 2: Interner Aufbau eines Unix-Dateisystems

Viele Leute glauben, dass ein regulärer Dateisystemcheck bei einem Journaling Filesystem nicht mehr erforderlich ist, da ja in ein Log-Buch (Journal) geschrieben wird. Nach einem Crash ist tatsächlich erheblich weniger Aufwand nötig, wenn Ext3, JFS, XFS oder ReiserFS verwendet werden. Allerdings schützt das nicht vor zufälligen Bit-Kippern oder anderweitig hervorgerufene Inkonsistenzen im Dateisystem.

Daher werden beim Third Extended Filesystem (Ext3), einer Erweiterung von Ext2, weiterhin Dateisystemchecks durchgeführt. Die Frequenz wird bei der Erstellung festgelegt und – so wie oben beschrieben – im Superblock festgehalten. Linux überprüft das Dateisystem jedoch nicht bei jedem Boot-Vorgang nach einem Problem, sondern nur wenn Max Mount Count überschritten ist oder lastcheck und checkinterval anzeigen, dass eine Überprüfung wieder an der Zeit ist.