© Alevtina Huzova, 123RF.com

Das Extended File System ist seit dem Linux-Kernel 0.96c ein treuer Begleiter des freien Betriebssystems. Mit seinen Weiterentwicklungen – oder sollte man sagen Wiedergeburten – Ext 2, Ext 3 und Ext 4 zählt es zu den ältesten Linux-spezifischen Softwareprojekten.

Der Linux-Kernel [1] ist mittlerweile fast 22 Jahre alt. Ein Weggefährte seit 1992 ist die Familie der “Erweiterten Dateisysteme” (Extended File Systems, Ext, [2], [3], [4]). Die ersten Schritte machte Linux mit einem von Minix stammenden Dateisystem ([3], [4], [5]). Dafür gab es mehrere Gründe: Linus Torvalds wollte ursprünglich ja nur einen besseren Terminal-Emulator für eben jenes Minix entwickeln. Daher bestand keine Notwendigkeit für eine eigene Datenablage. Selbst als sich das Torvalds-Projekt in einen Betriebssystemkern verwandelte, fand die Entwicklung weiter unter Minix statt. Das gemeinsame Dateisystem erleichterte dabei den Datenaustausch.

Ein Stern geht auf

Das Dateisystem des eigentlich für Lehrzwecke entwickelten Minix wies einige signifikante Einschränkungen auf. Die maximale Größe lag bei 64 MByte und die maximale Länge von Dateinamen betrug 14 Zeichen [4]. Für manche Linux-Pioniere waren diese Grenzen irgendwann nicht mehr tragbar, sie machten sich Gedanken über eine neues, Linux-natives Dateisystem. Mit Version 0.96a des Kernels integrierte Linus die VFS-Schicht (Virtual File System), die das Hinzufügen weiterer Dateisysteme erleichterte ([4], [6], Abbildung 1).

Abbildung 1: Der Linux-Kernel 0.96a brachte VFS gewissermaßen als Sprungbrett für das Ext-Dateisystem in 0.96c.

Mit Version 0.96c erblickte das erste Mitglied der Ext-FS-Familie das Licht der Linux-Welt [2]. Rémy Card, der Hauptautor, ließ sich hierbei vom Design des UFS (Unix File System) inspirieren. Nun durften Dateinamen 255 Zeichen lang sein, und zwar auf einem bis zu 2 GByte großen Dateisystem.

Das war aber nur der Anfang. Obwohl Ext eine Verbesserung gegenüber Minix-FS darstellte, gab es immer noch Punkte, die den Entwicklern absolut missfielen: Es gab nur einen statt der drei heute üblichen Datei-Zeitstempel. Die Verwendung von verlinkten Listen für freien Platz führte schnell zu Fragmentierung und schlechter Performance.

Die Ablösung von Ext war also vorprogrammiert und ließ nicht lange auf sich warten. Der Nachfolger Ext 2 ist seit Version 0.99.7 (März 1993) Bestandteil des Linux-Kernels. Die maximale Größe des Dateisystems konnte nun stolze 4 TByte betragen, eine Datei durfte bis zu 2 GByte umfassen. Das waren 1993 utopisch große Datenträger. Natürlich gab es nun auch die vertrauten drei Zeitstempel für die Erzeugung, die letzte Aktualisierung und den letzten Zugriff auf eine entsprechende Datei.

Konkurrent Xia

Interessanterweise war Ext 2 nicht konkurrenzlos ins Rennen gestartet. Xia-FS – benannt nach seinem Entwickler Frank Xia [6] – basierte auf Minix-FS und adressierte dessen Unzulänglichkeiten (Tabelle 1). Erste Alphaversionen gab es sowohl von Xia-FS als auch von Ext 2 im Januar 1993 – und Xia erwies sich zunächst sogar als stabiler. Die größere Entwicklergemeinde stand aber hinter dem Nachfolger von Ext und half dabei, diesen rasch stabil zu machen [7].

Die zweite Welle

Ext 2 war fast ein Jahrzehnt de facto das Standarddateisystem für Linux. Auch heute noch erfreut es sich signifikanter Beliebtheit: für Bootmedien oder zur Core-Dump-Datenablage. Die ersten Versionen stammten hauptsächlich aus der Feder des Franzosen Rémy Card, der schon Ext geschrieben hatte. Daneben machte sich Stephen Tweedie einen Namen als einer der Väter von Ext 2.

Theodore (Ted) Ts’o schließlich ist der Dritte im Bunde. Ihre 1994 veröffentlichte Arbeit zum Nachfolger von Ext ([8], auch [4]) ist eine gelungene Darstellung der Herkunft, des Status und der Entwicklungsmöglichkeiten des neuen Linux-Standarddateisystems. Wie schon der Vorgänger basiert Ext 2 auf den Designprinzipien von UFS und weist damit eine robuste Grundstruktur auf.

Das Konzept von Inodes, Verzeichnissen und Links erfordert kein Informatikstudium, um es zu verstehen (Abbildung 2): Nach dem Bootblock ist der Datenträger in so genannte Blockgruppen aufgeteilt. Am Beginn jeder Blockgruppe steht ein Superblock – oder dessen Backup –, der das Dateisystem beschreibt. Es folgen Informationen zur jeweiligen Blockgruppe. Mit den Bitmaps und Tabellen verwaltet das Dateisystem die (unbenutzten) Blöcke und Inodes.

Abbildung 2: Die grundlegende Struktur von Ext 2 stammt vom Unix-Dateisystem UFS.

Der verbleibende Platz gehört den eigentlichen Daten. Beim Design von Ext 2 hatten die Entwickler die Notwendigkeit zukünftiger Erweiterungen im Sinn. Bewusst ließen Rémy & Co. Platz in den Strukturen des Dateisystems, um dort später neue Merkmale hinterlegen zu können.

Die Anwender sollten dabei in den Genuss von neuen Funktionen kommen, ohne das Dateisystem neu anlegen zu müssen. Dieser recht einfach zu formulierende Ansatz ist eine wichtige Säule des Erfolgs der Ext-FS-Familie. Aufgrund der gut verstandenen Interna und der Tatsache, dass Ext-FS fast von Anfang an mit von der Partie war, diente Ext 2 oft als Testbasis für Erweiterungen der VFS-Schicht.

Journaling

Im Laufe der Zeit erhielt der Linux-Kernel immer mehr Dateisysteme. Reiser-FS, JFS oder XFS waren Ext 2 unter anderem in einem Punkt überlegen [9]: Dank des so genannten Journaling war ein »fsck« -Lauf bei ihnen wesentlich schneller als bei Ext 2. Mit immer größer werdenden Datenträgern trägt die Dateisystem-Überprüfung signifikant zur Dauer eines Betriebsausfalls bei. Stephen Tweedie veröffentlichte 1998 eine Designstudie mit ersten Implementationsansätzen für Ext 2 mit Journaling-Funktion [10].

Während der Diskussion zu Schreib-Performance-Problemen großer Dateien [11] meldete der Entwickler auf der Kernel-Mailingliste auch, dass er an dieser Erweiterung des Dateisystems arbeitete [12]. Die Verwaltung vieler Dateien in einem Verzeichnis machte Ext 2 einige Mühe. Die Entwickler adressierten dies mit der Einführung von H-Tree, einer speziellen Form des B-Tree.

Mit Journaling, der eben erwähnten baumartigen Struktur für große Verzeichnisse und der Möglichkeit, das Ext-FS online zu vergrößern, war Ext 3 geboren. Seit Version 2.4.15 (November 2001) ist es als Linux-Kernelbeigabe erhältlich [13]. Der Clou an der Sache: Eine Umwandlung von Ext 2 zu seinem Nachfolger war (und ist) ohne lästiges Daten-Herumschaufeln möglich.

Die Dateisystem-Entwickler hielten Wort. Mehr noch, sogar der Rückweg war möglich. Einfach das Kommando »fsck.ext2« über eine Ext-3-Partition laufen lassen, und schon konnte der Admin es wieder als normales Ext 2 in den Verzeichnisbaum einhängen. Noch eleganter geht es mit dem Werkzeug »tune2fs« (Listing 1).

01 # mkfs.ext2 /dev/sdb1
02 mke2fs 1.42.7 (21-Jan-2013)
03 Dateisystem-Label=
04 OS-Typ: Linux
05 Blockgröße=4096 (log=2)
06 Fragmentgröße=4096 (log=2)
07 [...]
08 Inode-Tabellen werden geschrieben: erledigt
09 Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt
10 # mount /dev/sdb1 /tmp/mnt/
11 # grep mnt /proc/mounts
12 /dev/sdb1 /tmp/mnt ext2 rw,relatime 0 0
13 # umount /tmp/mnt/
14 # tune2fs -j /dev/sdb1
15 tune2fs 1.42.7 (21-Jan-2013)
16 Erstelle Journal-Inode: erledigt
17 # mount /dev/sdb1 /tmp/mnt/
18 # grep mnt /proc/mounts
19 /dev/sdb1 /tmp/mnt ext3 rw,relatime,data=ordered 0 0
20 # umount /tmp/mnt/
21 # tune2fs -O ^has_journal,^dir_index /dev/sdb1
22 tune2fs 1.42.7 (21-Jan-2013)
23 # mount /dev/sdb1 /tmp/mnt/
24 # grep mnt /proc/mounts
25 /dev/sdb1 /tmp/mnt ext2 rw,relatime 0 0

Zurückrudern

Die Rückverwandlung einer Ext-3-Partition in Ext 2 erscheint dann sinnvoll, wenn Performance wichtiger als Dateisystem-Integrität ist. Ein Journal erfordert mehr Schreibzugriffe auf den Datenträger als bei Ext 2 und lässt sich leider nicht separat abschalten. Wie Listing 1 zeigt, ist die Konvertierung recht schmerzfrei und keine Einbahnstraße.

Aber die Geschichte wiederholte sich: Die Anforderungen bezüglich Größe und Geschwindigkeit der zu verwaltenden Datenträger wuchsen immer mehr und Ext 3 begann, an seine Grenzen zu stoßen. Aus einer Art gepatchtem Ext 3 entstand so Ext 4 [14]. Zunächst als experimentell gekennzeichnet, ist das Dateisystem seit Kernelversion 2.6.28 (Oktober 2008) als produktiv einsetzbar markiert.

Ted macht weiter

Die Kontinuität setzte sich auch auf Entwickler-Seite fort. Ted Ts’o, schon am Großvater von Ext 4 maßgeblich beteiligt und Chefverwalter von Ext 3, nahm auch den jüngsten Vertreter der Ext-FS-Familie unter seine Fittiche. Die neuen Merkmale von Ext 4 sind in [9] recht ausführlich beschrieben. Unbedingt hervorzuheben ist: Ein bereits vorhandenes Ext 3 lässt sich ohne Datenverlust oder -migration konvertieren.

Manche Neuerungen von Ext 4 erfordern aber leider eine Änderung der Struktur auf der Platte, dem so genannten On-disk-Format. Verzichtet der Admin auf diese, ist auch hier die Konvertierung keine Einweg-Operation. Wieder leistet das Programm »tune2fs« dem Administrator wertvolle Dienste. Es gibt sogar eine Light-Version, bei der Anwender eine Ext-3-Partition mit dem Ext-4-Treiber einbinden (siehe Abbildung 3).

Abbildung 3: Einige Verbesserungen von Ext 4 macht der Kernel über den Treiber auch für Ext-3-Partitionen verfügbar.

Die Beziehungen innerhalb der Ext-FS-Familie sind transitiv – aus der Kompatibilität von Ext 2 und Ext 3 sowie von Ext 3 und Ext 4 ergibt sich die Verträglichkeit von Ext 2 und Ext 4. Tabelle 2 zeigt auf, welcher Kerneltreiber mit welchem Dateisystem umgehen kann, ohne dass der Anwender die eigentlichen Daten auf der Platte manipulieren muss.

Nebenbasis: Bibliothek

Wie erwähnt war das gute Grundverständnis von Ext 2 mit seinen Nachfolgern ein wesentlicher Baustein für den Erfolg des Dateisystems. Neben den üblichen Werkzeugen zum Anlegen und Überprüfen von Ext-FS existieren auch gute Debuggingtools wie »debugfs« und »dumpe2fs« . Damit steigen ambitionierte Anwender richtig tief in das Dateisystem hinab, um es zu analysieren, Fehler zu beheben oder Daten zu retten.

Damit diese Tools funktionieren, müssen sie das entsprechende Insiderwissen über das jeweilige Mitglied der Ext-FS-Familie besitzen. Ändert sich ein Detail am Dateisystem, sind die Entwickler genötigt, auch die zugehörigen Werkzeuge anzupassen. Mit wachsender Anzahl der Helferprogramme kann der Pflegeaufwand immens werden. Der Trick bei Ext 2 und seinen Nachfolgern besteht darin, dass sich die Dateisystem-Infos in der Bibliothek »libext2fs« versammeln, gegen das die Tools gelinkt sind (Listing 2). Es ist schon Ironie, dass das Btr-FS-Werkzeug »btrfs-convert« ebenfalls diese Bibliothek benutzt. Es erlaubt nämlich, ein bestehendes Ext-FS in situ in den Konkurrenten Btr-FS zu konvertieren [15].

01 # ldd /usr/sbin/debugfs /usr/sbin/tune2fs \
02 > /usr/sbin/mkfs.ext*  /usr/sbin/fsck.ext* \
03 > /usr/sbin/btrfs-convert | grep ext2fs | \
04 >  awk '{print $1}' | uniq
05 libext2fs.so.2

Fazit

Mit ihrer über 20-jährigen Geschichte ist die Familie der Ext-Dateisysteme eines der nachhaltigsten Open-Source-Projekte im Linux-Umfeld. Maßgeblich für diesen Erfolg sind mehrere Faktoren: Zunächst das Design von 1993, das einerseits künftige Erweiterungen erlaubte, andererseits aber sehr stark rückwärtskompatibel war. Zudem herrscht Kontinuität bei den Chef-Entwicklern.

Die frühzeitige Integration in den Linux-Kernel war auch nicht gerade schädlich. Sie verhalf der Dateisystemfamilie zu einer großen Entwickler- und Anwendergemeinde. Dazu kam die frühe Nominierung zum Standarddateisystem von Linux. Sie ist gleichzeitig Ursache und Konsequenz des Erfolgs von Ext 2 und seinen Verwandten.

Es bleibt dennoch spannend, wie es in den kommenden Jahren weitergeht (siehe Kasten “Blick in die Zukunft”). Was passiert wohl nach der Wachablösung durch Btr-FS oder XFS? Wird das Handy-Linux Android die Fahne der Ext-Familienehre hochhalten? (mhu)