Journaling-Dateisysteme im Überblick

Das Dateisystem legt sich wie eine Schicht aus lauter winzigen Blöcken auf die Oberfläche der Platte. Anfangs ist diese Schicht geordnet, denn alle Daten liegen schön sauber hintereinander in zusammengehörigen Blöcken. Sobald jedoch die Schreibvorgänge beginnen, geht die Ordnung verloren. Dabei tritt der Effekt der externen Fragmentierung auf. Moderne Linux-Dateisysteme kommen mit dem Alterungsprozess besser zurecht als das in die Jahre gekommene Ext-2-Dateisystem. So hat ein ausführlicher Vergleich zwischen Ext 2 und ReiserFS[1] ergeben, dass ReiserFS deutlich geschickter auf die Leistungsbremse Fragmentierung reagiert.

Ausgedient haben ausgedehnte Kaffeepausen, wie sie fällig werden, wenn das Analysewerkzeug Fsck ein Ext-2-Dateisystem prüft. Neuere Linux-Dateisysteme protokollieren Änderungen in einem Katalog, der den Datenfundamenten ihren Namen gibt: Journaling-Dateisysteme. Dank des Journals hat das Fsck-Programm Inkonsistenzen bereits repariert, wenn »Fsck.ext2« noch untersucht, ob es überhaupt Fehler beseitigen muss. Grund: »Fsck.journal« prüft nur jene Daten, die älter sind als der letzte Eintrag im Journal. Der Rechner ist schneller einsatzbereit und die Verfügbarkeit verbessert sich.

Auf die Größe kommt es an

Wichtig ist die hohe Verfügbarkeit ohnehin, da der Datenberg unaufhörlich wächst und mit ihm auch die Kapazität der Hardware. Die Festplattenhersteller haben die 300-GByte-Grenze überschritten und Raid-Systeme verwalten schon längst mehrere Terabyte. Dateisystemdesigner denken allerdings weit über die heute verfügbare Hardware hinaus und schaffen Systeme, die mehr als eine Million Terabyte effizient verwalten können (siehe Tabelle 1). XFS von SGI führt bei der theoretisch möglichen Dateisystemgröße knapp mit 1,125 EByte vor ReiserFS, das bei 1 EByte an seine Grenze stößt. IBM folgt als Dritter mit 32 PByte. Ext 3 hält sich an die Leistungsgrenze des Kernels 2.6, der die Dateisystemgröße auf 16 TByte beschränkt.

Geht der Speicherplatz zur Neige, vergrößert der Benutzer das Dateisystem im laufenden Betrieb. Sinnvoll ist dies vor allem im Zusammenhang mit einer logischen Festplatte (LVM) oder einem Software-Raid. Mit beiden Techniken beschäftigt sich der Artikel "Datenkoppler" in dieser Ausgabe.

Dateisysteme im Kernel 2.6

Für jedes der Dateisysteme Ext 3, JFS, ReiserFS und XFS befinden sich Treiber im Kernel 2.6, wodurch der Anwender nun bequem testen kann, ohne die Originalquellen zu patchen. Neben den blanken Treibern enthält der Kernelbaum auch fortschrittliche Funktionen wie Quotas, Access Control Lists (ACL) und Unterstützung für Debugging (Abbildung 1). Gleich bleibt, dass das Dateisystem der Root-Partition in den Kernel kompiliert sein muss, falls der Admin keine Initial-RAM-Disk verwendet. Wie gewohnt kann der Benutzer die Dateisystemtreiber auch als Modul übersetzen und zur Laufzeit laden.

Abbildung 1: Ext 2/3, JFS, ReiserFS und XFS haben den Sprung in den Kernel 2.6 geschafft. Unterschiede sind beim ACL-Support sowie bei Quotas und Debug-Funktionen zu verzeichnen.

Was die Verwaltung von Dateisystemrechten angeht, riefen die Netzwerkadministratoren in letzter Zeit immer deutlicher nach ACLs. Diese erweitern das übliche Rechteschema Eigentümer, Eigentümergruppe und andere, sodass der Admin beispielsweise entfernten Windows-Benutzern einfach Zugriff auf Dateien auf einem Samba-Server geben kann. Für den Windows-Benutzer erscheinen die Dateirechte so, als greife er statt auf Samba auf einen Windows-NT/2000-Server zu. Mehr zur Konfiguration bei ACLs ist auf den Websites[2] und[3] zu finden.