23.9Dateisystemgrundlagen

Im Mittelpunkt der folgenden Seiten stehen die Linux-Dateisysteme ext2, ext3, ext4, btrfs und xfs. Bevor ich deren Einrichtung und Administration beschreibe, gibt dieser Abschnitt einige Grundlageninformationen, die unabhängig vom Dateisystemtyp sind.

Alle gängigen Linux-Dateisysteme unterstützen Journaling-Funktionen. In seiner einfachsten Form bedeutet Journaling, dass der Beginn und das Ende jeder Dateioperation in einer speziellen Datei mitprotokolliert werden. Dank des Protokolls kann später geprüft werden, ob eine bestimmte Dateioperation vollständig ausgeführt wurde. Wenn das nicht der Fall ist, kann die Operation widerrufen werden. In der Datenbankwelt spricht man hier von Transaktionen.

Bei fortgeschrittenen Journaling-Systemen besteht die Möglichkeit, die eigentlichen Änderungen an den Dateien im Journal zu protokollieren. Das verlangsamt den gewöhnlichen Betrieb, gibt aber mehr Möglichkeiten zur späteren Rekonstruktion.

Wenn nun eine Dateioperation nicht vollständig abgeschlossen werden kann, geht dies aus dem Protokoll hervor. Bei einfachem Journaling sind die Änderungen zwar verloren, der bisherige Zustand der Datei steht aber zumeist noch zur Verfügung. Versprechen Sie sich also keine Wunder von der Journaling-Funktion!

Der große Vorteil der Journaling-Funktionen besteht darin, dass das Dateisystem beim nächsten Rechnerstart sehr rasch wieder in einen konsistenten Zustand gebracht und beinahe sofort wieder genutzt werden kann. Das ist ein großer Unterschied im Vergleich zu früher, wo nach einem Absturz oder Stromausfall das gesamte Dateisystem systematisch nach eventuellen Fehlern durchsucht werden musste. Das dauerte mehrere Minuten, bei sehr großen Festplatten eventuell sogar Stunden.

Bei einem Stromausfall gibt auch Journaling keine Garantie für ein konsistentes Dateisystem! Das Problem liegt bei den Festplatten bzw. SSDs: Diese verwenden aus Effizienzgründen beim Schreiben einen internen Zwischenspeicher. Daher kann es passieren, dass das Dateisystem vom Datenträger die Bestätigung erhält, dass er die Daten empfangen und gesichert hat. Tatsächlich kann es danach aber noch Sekunden dauern, bis die Daten vom Zwischenspeicher physikalisch auf die Festplatte geschrieben werden. Bei SSDs ist diese Zeitspanne viel kürzer, aber das ändert nichts am prinzipiellen Problem.

Tritt in dieser Zeitspanne ein Stromausfall auf, gehen die Daten im Zwischenspeicher verloren. Bei manchen Festplatten lässt sich dieser Cache deaktivieren. Dadurch verringert sich die Geschwindigkeit von Schreiboperationen aber derart, dass in der Praxis zumeist darauf verzichtet wird.

Unabhängig vom Schreib-Cache ist das Verhalten einer Festplatte während eines plötzlichen Stromausfalls undefiniert. Es kann also auch passieren, dass die Festplatte statt Ihrer Daten Zufallsbits schreibt, bevor der Schreibkopf in Sicherheit gebracht wird. Eine Diskussion zu diesem Thema finden Sie hier:

http://lwn.net/Articles/191352

Anders formuliert: Journaling-Dateisysteme sind eine feine Sache, schließen einen Datenverlust bei einem Stromausfall aber nicht aus.

Wenn Linux beim Starten erkennt, dass der Rechner zuletzt nicht ordnungsgemäß heruntergefahren wurde, führt es für die Systempartition und je nach Konfiguration auch für andere in /etc/fstab genannte Partitionen eine Überprüfung des Dateisystems durch. Ob eine Überprüfung stattfindet oder nicht, entscheidet die sechste Spalte in /etc/fstab. Dank der Journaling-Funktionen ist diese Überprüfung normalerweise blitzschnell erledigt.

Davon losgelöst sehen einige Dateisysteme (unter anderem ext in allen Versionen) eine regelmäßige Überprüfung des Dateisystems auf Konsistenzfehler vor. Diese relativ zeitaufwendigen Tests erfolgen beim Start des Rechners, wenn seit dem letzten Test eine bestimmte Zeitspanne oder Anzahl von mount-Vorgängen überschritten wurde.

Nach der Einführung der Journaling-Funktionen wurde vielfach argumentiert, der regelmäßige Konsistenztest sei jetzt überflüssig. Das stimmt aber leider nicht ganz: Ein Dateisystem kann auch durch Hardware-Fehler der Festplatte inkonsistent werden – und die Wahrscheinlichkeit solcher Fehler steigt mit der zunehmenden Festplattengröße!

Beispielsweise habe ich im Datenblatt meiner 1-TByte-Festplatte die Angabe gefunden, dass die Wahrscheinlichkeit für Bitfehler (Nonrecoverable Read Errors per Bits Read) kleiner als 1 zu 10¹⁵ ist. Das klingt wirklich vernachlässigbar. Wenn Sie allerdings in Rechnung stellen, dass auf dieser Festplatte 8 × 10¹² Bits Platz finden, wird klar, dass Datenfehler im regulären Betrieb – also ohne irgendwelche Beschädigungen – sehr wohl zu erwarten sind. Ein regelmäßiger Konsistenztest des Dateisystems kann diese Fehler zwar nicht verhindern, bietet aber eine gewisse Chance, ein Fehlverhalten festzustellen und zu korrigieren, zumindest dann, wenn für die interne Verwaltung des Dateisystems kritische Bereiche betroffen sind.

Wirklich fehlertolerant sind die in diesem Buch vorgestellten Dateisysteme leider alle nicht. Dateisysteme, die durch Prüfsummen Hardware-Fehler erkennen bzw. durch redundante Speicherung derartige Fehler sogar korrigieren können, sind aber ein hochaktuelles Forschungsgebiet.

Eine manuelle Überprüfung können Sie einfach mit dem Kommando fsck durchführen. Die betreffende Partition darf während der Kontrolle allerdings nicht verwendet werden, d.h., Sie müssen vorher umount ausführen.

Die Systempartition können Sie im laufenden Betrieb allerdings nicht überprüfen, weil Sie das Dateisystem nicht mit umount abmelden können.

Stattdessen führen Sie als root das Kommando touch /forcefsck aus und starten den Rechner neu. Die Datei forcefsck wird auch erzeugt, wenn Sie shutdown mit der zusätzlichen Option -F ausführen.

Wenn die Datei /forcefsck existiert, wird bei fast allen Distributionen beim nächsten Start automatisch eine Überprüfung des Dateisystems durchgeführt.

Sollte das nicht funktionieren, fahren Sie den Rechner mit einem Rescue- oder Live-System hoch und führen fsck von dort aus.

In der Vergangenheit tauchte immer wieder die Frage auf, wie groß Dateien maximal sein dürfen. Die Antwort hängt davon ab, welchen Kernel, welche CPU-Architektur, welche glibc-Bibliothek und welches Dateisystem Sie verwenden. Aktuelle Distributionen unterstützen durchweg die LFS-Erweiterungen in der glibc-Bibliothek. LFS steht dabei für Large Filesystem Support. Die Dateigröße ist dank LFS mit 2⁶³ Byte nahezu unbegrenzt. Zum anderen geben aber auch die verschiedenen Dateisystemtypen Limits für die maximale Datei(system)größe vor. Tabelle 23.6 fasst die Daten zusammen. Dabei gilt: 1 TByte (Terabyte) = 1024 GByte.

Dateisystem	Maximale Dateigröße	Maximale Dateisystemgröße
btrfs	16.777.216 TByte	16.777.216 TByte
ext3	2 TByte	32 TByte (bei 8 kByte Blockgröße)
ext4	16 TByte	1.048.576 TByte = 1 Exabyte
xfs	9.437.184 TByte	9.437.184 TByte
ZFS	16.777.216 TByte	16.777.216 TByte

Tabelle 23.6Maximale Dateisystemgröße

Eine Umwandlung des Dateisystemtyps ist in der Regel unmöglich. Der einzige Weg besteht darin, ein neues Dateisystem im gewünschten Typ einzurichten und dann alle Dateien zu kopieren. Zu den wenigen Ausnahmen zählte btrfs-convert zur Konvertierung von ext3/-4 nach btrfs. Dieses Kommando wird aber nicht mehr offiziell unterstützt.