Wer heute mit einem handelsüblichen Computer arbeitet, verwendet automatisch auch eine Festplatte. Wie die Dateien dort gespeichert werden und welche Möglichkeiten dabei geboten werden, weiß hingegen kaum jemand. Dieser Artikel will etwas Licht ins Dunkel bringen.

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.

Hard- und Symlinks

Die generelle Struktur des Dateisystems ist in Abbildung 2 dargestellt. Speichert Linux Dateien, reserviert der Treiber für das entsprechende Dateisytem im Kernel einen I-Node und mehrere Datenblöcke. Der I-Node verweist auf die Datenblöcke, in denen die eigentlichen Daten gespeichert werden. Der Name der Datei wird darüber hinaus zusammen mit dem I-Node im Verzeichnis gespeichert.

Unix ist für eine Besonderheit im Dateisystem bekannt: die so genannten Links. Mit Hilfe von Links ist es möglich, eine Datei in mehrere Verzeichnisse aufzunehmen und somit über unterschiedliche Namen auf sie zuzugreifen. Das hat in vielerlei Hinsicht Sinn.

Ein sinnvoller Einsatz von Links liegt beispielsweise vor, wenn ein Programm mehrere Funktionen übernimmt, die sich nur in wenigen Operationen unterscheiden. Anstatt zwei oder mehrere ähnliche Programme zu schreiben, kann das Programm beim Aufruf den eigenen Namen überprüfen und sich entsprechend verhalten. Das ist zum Beispiel bei den Programmen gzip und gunzip sowie den M-Tools (mdir und mcopy) der Fall.

Der Alternativen-Mechanismus von Debian arbeitet auf ähnliche Weise. Der Programmname (beispielsweise /usr/bin/vi) ist ein Link auf eine Datei in /etc/alternatives, von wo zum tatsächlichen Programm gelinkt wird. Wer sich einen langen Pfadnamen nicht merken möchte, kann einen Link in ein eigenes Verzeichnis aufnehmen, der auf die gewünschte Datei zeigt, und sich somit Tipparbeit sparen.

Die Verwendung von Links hat gegenüber einer Kopie der Datei große Vorteile: Zum einen muss die Datei nicht kopiert werden. Wenn es sich um CD-Images handelt, kann das viel Speicherplatz ausmachen. Zum anderen muss die Kopie nicht mit dem Original synchronisiert werden, da Änderungen automatisch aus Sicht des Links sichtbar sind. Es wird ja immer noch die ursprüngliche Datei für die Daten verwendet.

Es gibt allerdings zwei unterschiedliche Typen von Links, wobei ein Typ auf zwei unterschiedliche Arten im Dateisystem gespeichert wird. Prinzipiell wird zwischen Hard- und Symlinks unterschieden. Beim Hardlink verweisen mehrere Verzeichniseinträge auf den gleichen I-Node, beim Symlink wird der Name der ursprünglichen Datei gespeichert.

Hardlinks

Ein Hardlink ist die einfachste und effizienteste Möglichkeit, auf eine Datei über mehrere Namen zuzugreifen. Bei dieser Methode wird wie bei einer herkömmlichen Datei ein neuer Verzeichniseintrag angelegt. Allerdings wurden vorher weder ein neuer I-Node noch ein neuer Datenblock angefordert, sondern es wird der I-Node der ursprünglichen Datei verwendet. Von nun an zeigen zwei Verzeichniseinträge auf den gleichen I-Node.

Dies muss natürlich irgendwo notiert werden, denn der I-Node und die zugehörigen Datenblöcke dürfen erst dann gelöscht werden, wenn kein Verzeichniseintrag mehr auf den I-Node verweist. Für diesen Zweck ist im I-Node das Feld links_count vorgesehen, das bei einem Hardlink um 1 erhöht wird. Dort steht nach Anlegen dieses Links der Wert 2 und nicht mehr 1, da zwei Verzeichniseinträge auf diesen I-Node zeigen.

Abbildung 3: Hardlink im Dateisystem

Aus Sicht des Dateisystems sind beide Verzeichniseinträge vollkommen gleichwertig. Wenn ein solcher Eintrag gelöscht werden soll, dann löscht das Dateisystem den jeweiligen Eintrag im Verzeichnis und reduziert den Zähler im I-Node. Erst wenn dieser Zähler den Wert 0 ergibt, werden auch der I-Node gelöscht und der belegte Speicherplatz freigegeben.

In Abbildung 3 wird die Umsetzung des nachfolgenden Link-Befehls im Dateisystem dargestellt.

ln foo bar

Die Datei foo ist dabei die ursprüngliche Datei, und bar ist der neue, zusätzliche Name für sie. Wie man sieht, wird pro Hardlink nur ein zusätzlicher Eintrag im Verzeichnis benötigt, also sehr wenig zusätzlicher Speicherplatz.

I-Nodes werden jedoch nur innerhalb des selben Dateisystems eindeutig vergeben. Hardlinks können daher nicht Dateisystem-übergreifend verwendet werden. Symbolische Links (Symlinks) können dagegen von einem Dateisystem auf ein anderes verlinken.

Der Wert von links_count wird üblicherweise von ls -l angezeigt. Es ist das zweite dargestellte Feld (das erste beschreibt die Berechtigungen).

Symbolische Links

Symbolische Links oder kurz Symlinks sind die zweite Möglichkeit, über mehrere Namen auf die gleiche Datei zuzugreifen, ohne die ursprüngliche Datei kopieren zu müssen. Bei einem Symlink wird wie bei einer herkömmlichen Datei ein I-Node für den neuen Eintrag angefordert und im Verzeichnis eingetragen.

Abbildung 4: Darstellung eines “schnellen” Symlinks im Dateisystem

Allerdings verweist beim Symlink der I-Node auf den Namen der ursprünglichen Datei. Wenn der Name kurz genug ist, kann er sogar im I-Node selbst gespeichert werden: Dort ist Platz für 29 Zeichen. Das ist in Abbildung 4 illustriert, in der die Auswirkungen des folgenden Befehls dargestellt werden.

ln -s foo bar

Wenn der Pfadname der ursprünglichen Datei länger ist, insbesondere wenn der Name den vollständigen Pfad und nicht nur den Dateinamen der ursprünglichen Datei enthält, kann er nicht mehr im I-Node gespeichert werden. Dann muss stattdessen ein eigener Datenblock angefordert werden, in dem der Pfad zur ursprünglichen Datei gespeichert wird. In Abbildung 5 wird das Ergebnis des Befehls

ln -s /org/infodrom.org/home/joey/foo bar

illustriert.

Abbildung 5: Darstellung eines “langsamen” Symlinks im Dateisystem

Es dürfen im Übrigen relative Pfade wie ../joey/foo verwendet werden. Dabei sollte man allerdings aufpassen: Wird der Link in eine andere Verzeichnisebene verschoben, stimmt der Pfad nicht mehr, und der Link zeigt ins Leere.

Bei Symlinks wurde das Feld links_count bisher nicht erwähnt, da es wie bei einer herkömmlichen Datei behandelt wird, also üblicherweise den Wert 1 enthält. Wird die ursprüngliche Datei gelöscht, verschwindet mit dem Verzeichniseintrag die Verbindung zum Symlink. Der symbolische Link selber bleibt bestehen; er ist davon technisch gesehen nicht betroffen. Allerdings zeigt er jetzt ins Leere. In der Fachsprache wird das hängender Symlink, “Dangling Symlink”, genannt.

Dateisystem-Check

Beim Start eines Linux-Systems wird das Root-Dateisystem zuerst nur lesbar ins System eingehängt, um Programme auszuführen und Konfigurationsdateien auszulesen. In einer der nächsten Aktionen des Boot-Vorgangs überprüft Linux alle lokalen Unix-artigen Dateisysteme (Minix, Ext2, Ext3, XiaFS, ReiserFS, XFS, JFS).

Ist ein Dateisystem “unsauber”, da es nicht ordentlich aus dem laufenden System entfernt wurde, steht ein Check an, denn dann ist die Wahrscheinlichkeit recht hoch, dass sich das Dateisystem in einem inkonsistenten Zustand befindet: Letzte Änderungen wurden möglicherweise nicht vollständig übernommen. Bei einem Dateisystem mit Journal liest Linux das Journal ein und überprüft, ob alle Aktionen zuende geführt werden. Danach sollte sich das Dateisystem wieder in einem konsistenten Zustand befinden.

Der Check besteht für das Dateisystem Ext2 aus fünf Schritten. So sorgt Linux dafür, dass die Datenstrukturen konsistente Informationen enthalten. Es wird die generelle Konsistenz des Dateisystems geprüft. Dazu muss es mindestens einmal vollständig durchlaufen werden, was diesen Check bei großen Dateisystemen so zeitaufwendig macht.

Während dieses Checks überprüft das Programm fsck, dass der Wert im Feld links_count in den I-Nodes mit der Anzahl der Verweise aus den Verzeichnissen übereinstimmt. Gibt es dort Differenzen, aktualisiert fsck das Feld. Das gleiche gilt für Größenangaben.

Falls der Check I-Nodes findet, für die kein Verzeichniseintrag existiert, dann legt die Software sie im speziellen Verzeichnis lost+found ab. Der Administrator entscheidet anschließend, ob die Datei gelöscht oder an einen passenden Platz verschoben werden soll.

Dateisystem erzeugen

Für das Erzeugen von Dateisystemen stehen unter Linux mkfs-Programme zur Verfügung. Um ein einheitliches Namensschema zu bieten, wird der Name des jeweiligen Programms aus dem Präfix mkfs. und dem zu erzeugenden Dateisystem gebildet, beispielsweise mkfs.ext3 für das Ext3-Dateisystem.

Auf einem Linux-Rechner wird meistens das “Third Extended Filesystem” (Ext3) oder das Reiser-Dateisystem (ReiserFS) verwendet. Über verschiedene Parameter lässt sich einstellen, wie das jeweilige Programm das Dateisytem erzeugen soll. Dies betrifft insbesondere die Anzahl der I-Nodes, die die maximale Anzahl von erzeugbaren Dateien und Verzeichnissen auf diesem Dateisystem bestimmt.

Der Parameter -b legt die Größe der Blöcke im Dateisystem fest. Ohne besondere Einstellungen werden 1024 Byte große Datenblöcke verwendet. (Der Wert kann auf neueren Systemen abweichen.) Es werden also jeweils zwei physikalische Blöcke auf der Festplatte zu einem logischen Datenblock zusammengefasst. Mit dem Parameter -b kann diese Einstellung jedoch geändert werden. Allerdings dürfen nur Vielfache von 1024 angegeben werden, und zwar nur 1024, 2048 und 4096.

Auf Dateisytemen mit vielen großen Dateien kann eine größere Blockgröße sinnvoll sein. Zugriffe können somit beschleunigt werden. Allerdings ist der Verschnitt auch größer, denn es können immer nur ganze Blöcke pro Datei zugewiesen werden. Eine 5000 Byte große Datei würde somit in unserem Beispiel 3192 Bytes im zweiten logischen Block verschwenden.

Eine weitere interessante Option beschreibt den für root reservierten Bereich. Normalerweise sind fünf Prozent des Dateisystems für den Superuser reserviert. Dies stellt sicher, dass das System auch dann weiterläuft, wenn das Dateisystem fast voll ist. Unter root ausgeführte Programme können dann weiterhin auf das Dateisystem schreiben.

Diese Einstellung wird mit -m überschrieben. Auf Dateisystemen, die nur für Benutzerdaten und nicht für Systemdaten gedacht sind, wie z. B. /home oder /var/spool/news, kann es sinnvoll sein, auf diesen Sicherheitsbereich vollständig zu verzichten.

Der Parameter -i bestimmt, in welchem Verhältnis zu den Nutzdaten I-Nodes erzeugt werden sollen. Wenn auf dem Dateisystem hauptsächlich große Dateien erzeugt werden, ergibt es wenig Sinn, für je 4 KB einen I-Node vorzusehen. Da wären 10 KB oder gar 100 KB pro I-Node vielleicht sinnvoller.

Abbildung 6: Erzeugen eines Ext3-Dateisystems mit Journal

Anders herum ist es nicht sinnvoll, auf einem Dateisystem mit sehr vielen kleinen Dateien (beispielsweise News-Artikel) erst alle 4 Kilobyte einen I-Node vorzusehen. Dort kann für jeweils 2048 Bytes ein I-Node erzeugt werden. Im laufenden Betrieb lässt sich die Anzahl der I-Nodes nicht mehr ändern.

Erzeugt man ein Dateisystem mit Journal, also Ext3 statt Ext2, wird der Parameter -j verwendet, um dies festzulegen. Da die Dateistyseme Ext2 und Ext3 zueinander kompatibel sind, kann ein Ext2-Dateisystem auch nachträglich in ein Ext3-Dateisytem mit Journal umgewandelt werden. Das erledigt der Befehl tune2fs.

Dateisystem untersuchen

Normalerweise erhält man keinen Einblick in das Dateisytem und wie es funktioniert. Unter Linux besteht jedoch die Möglichkeit, zumindest einen Blick in die aktuelle Konfiguration des Dateisystems zu werfen, auch im laufenden Betrieb. Für diese Funktion steht das Programm dumpe2fs zur Verfügung. Dabei werden hauptsächlich die im Superblock gespeicherten Informationen angezeigt. Bei einem funktionierenden Superblock wird auch die Position der Kopie des Superblocks angezeigt.

Abbildung 7: Ausgabe von dumpe2fs für eine Ext3-Partition (gekürzt)

Wie aus der Ausgabe von dumpe2fs eines aktuellen Dateisystems erkennbar ist, wird, die Kopie des Superblocks nicht im Block 8193, sondern in Block 32768 gespeichert. Das liegt an unterschiedlichen Einstellungen des Dateisystems.

Recovery

Die Kenntnis der Position der Superblocks-Kopie, von dumpe2fs als Backup Superblock bezeichnet, kann extrem wichtig werden. Wenn der originale Superblock zerstört ist, kann das Dateisystem nicht mehr überprüft werden und folglich auch nicht mehr ins System eingehängt werden. Die Daten sind jedoch noch nicht verloren, denn vom Superblock wird ja eine Kopie gespeichert.

Das Dateisystem lässt sich damit restaurieren, wenn explizit die Position des Backup-Superblocks angegeben wird. Der Aufruf des Prüfprogramms sieht dann wie folgt aus:

e2fsck -b 8193 /dev/hda3

beziehungsweise (je nach Position des Superblock-Kopie)

e2fsck -b 32768 /dev/hda3

Anschließend sollte das Dateisystem wieder wie bisher verwendet werden können.