Ext2
Das ext2 oder auch Second extended Filesytem war viele Jahre lang das Standard-Dateisystem des Linux-Betriebssystems und ist immer noch weit verbreitet. Es wurde ursprünglich 1993 von Rémy Card auf Basis des Extended Filesystem v1 entwickelt, die heutige Implementation im Linux-Kernel stammt sowohl von ihm als auch Theodore Ts'o und Stephen Tweedie. Desweiteren existieren Implementationen für NetBSD, FreeBSD, GNU HURD, Microsoft Windows, OS/2 und RISC OS. Hauptnachteil von ext2 ist, dass es kein Journaling-Dateisystem ist. Es verliert daher zunehmend Benutzer an ReiserFS und an seinen abwärtskompatiblen Nachfolger ext3. ext3 wird in diesem Artikel weiter unten besprochen.
Spezifikation
ext2 teilt viele seiner Eigenschaften mit traditionellen Unix-Filesystemen, z. B. das Konzept der Blöcke, Inodes und Verzeichnisse. Wenn gewünscht, ist es um Eigenschaften wie Zugriffskontrollisten (ACLs), Fragmente, Wiederherstellung gelöschter Daten und Kompression erweiterbar. Die meisten der genannten Funktionen sind nicht serienmäßig implementiert, sondern existieren nur als Patches. Weiterhin gibt es einen Versionsmechanismus, der es erlaubt, neue Funktionen abwärtskompatibel hinzuzufügen (wie dies bei der Journaling-Erweiterung ext3 geschehen ist). Alle Informationen werden auf einem ext2-System im Little Endian-Format abgelegt, so dass ein Dateisystem auf verschiedenen Architekturen eingehängt werden kann, ohne dass plötzlich die "Lesrichtung" nicht mehr stimmt.
Wenn das Dateisystem Revision 1 oder neuer ist, gibt es im Superblock weitere Felder, die den Volume-Namen, eine eindeutige Identifikationsnummer und die Inode-Größe angeben, sowie Platz für die Konfigurationsinformationen optionaler Dateisystem-Funktionen bieten.
Es gibt einige ungenutzte Felder und überladene Felder in der Inode-Struktur. Ein Feld ist für die Verzeichnis-ACL reserviert, wenn der Inode ein Verzeichnis ist, alternativ hält dieses Feld die oberen 32 Bit der Dateigröße, wenn der Inode eine reguläre Datei ist (dies erlaubt Dateigrößen > 2 GB). Die meisten der übrigen Felder werden von Linux und HURD als vergrößerte Besitzer- und Gruppenfelder genutzt. HURD kennt außerdem zusätzliche Felder für erweiterte Rechteverwaltung und den Inode des Programms, das diesen Inode üblicherweise interpretiert.
Es gibt im Inode Pointer auf die ersten 12 Blöcke, die die Daten der Datei enthalten. Außerdem gibt es einen Pointer auf einen indirekten Block (der wiederum Pointer auf den nächsten Satz von Blöcken der Datei enthält), einen Pointer auf einen doppelt indirekten Block (der Pointer auf weitere indirekte Blöcke enthält), und einen Pointer auf einen dreifach indirekten Block (der Pointer auf doppelt indirekte Blöcke enthält).
Das Flags-Feld enthält einige ext2-spezifische Flags, die nicht durch chmod etc. beeinflusst werden können. Diese Flags können mit lsattr gelistet werden und mit chattr geändert werden, und erlauben einer Datei besonderes Verhalten. Es gibt Flags für sicheres Löschen, Unlöschbarkeit, Kompression, synchrone Updates, Schreibschutz, indexierte Verzeichnisse, Journaling und einiges mehr. Nicht alle Flags lassen sich derzeit sinnvoll verwenden.
Zeichen- und Blockorientierte Geräte haben nie Datenblöcke zugewiesen. Stattdessen wird die vom Kernel vergebene Geräte-Nummer im Inode abgelegt, wobei wiederum die Pointer-Felder auf Datenblöcke benutzt werden.
Ein COMPAT-Flag bedeutet, dass das Dateisystem ein Feature enthält, aber das Datenformat auf der Platte 100 % kompatibel mit älteren Formaten ist, so dass ein Kernel, der diese Funktion nicht kennt, im Dateisystem lesen und schreiben könnte, ohne es inkonsistent zu machen. Bestes Beispiel für ein COMPAT-Flag ist die Funktion HAS_JOURNAL eines ext3-Dateisystems. Ein Kernel ohne ext3-Unterstützung kann ein solches Dateisystem problemlos als ext2fs einhängen und dann quasi unter Umgehung des Journals darauf schreiben, ohne irgendetwas zu beschädigen.
Ein RO_COMPAT-Flag zeigt an, dass das Datenformat des Dateisystems beim Lesen 100 % kompatibel mit älteren Formaten ist. Ein Kernel ohne Kenntnis der in Frage stehenden Funktion könnte jedoch das Dateisystem korrumpieren, wenn er darauf schreibt, daher wird dies verhindert. Ein Beispiel für ein lesekompatibles Feature ist SPARSE_SUPER, ein Dateisystem-Layout, bei dem weniger Superblock-Backups als normal üblich auf dem Datenträger abgelegt werden. Ein alter Kernel kann problemlos von einer solchen Festplatte lesen, wenn er jedoch einen Schreibversuch unternehmen würde, würden seine Schreibroutinen irreführende Fehlermeldungen produzieren, und evtl. die Bitmaps inkonsistent werden.
Ein INCOMPAT-Flag zeigt an, dass sich das Datenformat so geändert hat, dass Kernels ohne dieses Feature weder schreiben noch lesen oder auch nur mouten könnten. Als Beispiel für eine inkompatible Zusatzfunktion kann die optionale Kompression dienen; Ein Kernel, der die Daten nicht dekomprimiert, würde nur "Müll" vom Datenträger lesen. Auch ein inkonsistenstes ext3-Dateisystem ist so lange inkompatibel, bis ein ext3-fähiger Kernel das Journal abgespielt hat und die Inkonsistenzen beseitigt hat. Danach kann das ext3-System auch wieder als ext2 eingehangen werden.
Das Hinzufügen neuer Features zum ext2/3-Dateisystem erfordert auch immer ein Update des zugehörigen Toolkits e2fsprogs, da die darin enthaltenen Prüfungswerkzeuge in der Lage sein müssen, alle Dateisystem-Features zu kennen, um eine zuverlässige Feststellung und Behebung von Inkonsistenzen zu ermöglichen.
Das Dateisystem begrenzt die Anzahl von Unterverzeichnissen in einem gegebenen Verzeichnis auf 32.768 Stück. Weiterhin wird angewarnt, wenn in einem Verzeichnis mehr als ca. 10.000 - 15.000 Dateien liegen, da Dateioperationen in solch großen Verzeichnissen lange dauern können. Die tatsächlich maximal mögliche Anzahl von Dateien ist wieder akademischer Natur, da man Schwierigkeiten haben wird, genügend eindeutige Dateinamen zu finden, bevor man an das Limit von 130 Trillionen Dateien pro Verzeichnis stößt. Handhabbar wären solche Verzeichnisse ohnehin nicht mehr.
Wenn eine Änderung am Dateisystem (z. B. die Umbenennung einer Datei) durchgeführt wird, wird sie als Transaktion im Journal vermerkt und kann dann im Falle eines Absturzes entweder abgeschlossen oder noch nicht abgeschlossen sein. Wenn eine Transaktion zum Crashzeitpunkt (oder im Normalfall, wenn das System nicht abstürzt) abgeschlossen war, ist garantiert, dass alle an dieser Transaktion beteiligten Blöcke einen gültigen Dateisystemstatus repräsentieren. Diese Blöcke werden dann ins Dateisystem kopiert. Wenn eine Transaktion zum Crashzeitpunkt nicht abgeschlossen war, kann nicht garantiert werden, dass die beteiligten Blöcke konsistent sind, daher wird eine solche Transaktion verworfen (das bedeutet, dass die Dateisystem-Änderung, die diese Transaktion repräsentierte, verloren geht).
Bei abgebrochenen Schreiboperationen kann es passieren, dass ein Teil einer Datei bereits aus den neuen Daten besteht und ein Teil noch aus den alten, was manchmal noch schlimmer sein kann als ein inkonsistentes Dateisystem. ext3 bietet daher einen besonderen Modus, in dem auch Daten zunächst im Journal abgelegt werden. ext3 schützt nicht davor, dass Daten verloren gehen, die zum Crashzeitpunkt zwar eigentlich bereits auf die Platte geschrieben sein sollten, vom Kernel jedoch noch in so genannten "schmutzigen Puffern" gehalten wurden, um sie später zurückzuschreiben. Nach dem Abspielen des Journals ist nur garantiert, dass man mit einem konsistenten Datenbestand zu einem gegebenen Zeitpunkt weiterarbeiten kann.Blöcke
Der Platz auf einem mit ext2 formatierten Gerät oder Datei (man kann ext2-Systeme in Dateien ablegen, die wiederum auf anderen Dateisystemen liegen) wird in Blöcke aufgeteilt. Diese haben eine feste Größe von 1 kB, 2 kB oder 4 kB (8 kB auf Alpha-Architekturen). Die Größe der Blöcke wird bei der Erstellung des Dateisystems festgelegt. Kleinere Blöcke führen zu weniger verschwendetem Platz pro Datei, benötigen aber etwas mehr Overhead bei der Verwaltung, und begrenzen indirekt auch die maximale Größe von Dateien und dem ganzen Dateisystem.Blockgruppen
Blöcke werden in Blockgruppen zusammengefasst, um Fragmentierung zu reduzieren und den Zugriff auf große Mengen aufeinander folgender Daten zu beschleunigen, indem die nötigen Kopfbewegungen der Festplatte minimiert werden. Die Informationen über jede Blockgruppe werden in einer Deskriptor-Tabelle abgelegt, die direkt hinter dem Superblock liegt.
Zwei Blöcke in der Nähe des Beginns der Blockgruppe sind für zwei Bitmaps reserviert, die die Block- und Inode-Belegung in der Gruppe anzeigen. Da jede Bitmap nur einen Block belegen kann, ist die maximale Größe jeder Blockgruppe auf achtmal die Größe eines Blockes begrenzt. Die auf die Bitmaps folgenden Blöcke fungieren als Inode-Tabelle für die Blockgruppe, und die übrigen sind als Datenblöcke nutzbar.Der Superblock
Der Superblock enthält alle Informationen über die Konfiguration des Dateisystems. Der primäre Superblock liegt 1024 Byte hinter dem Beginn des Gerätes, und ist wichtig, um das Dateisystem einbinden (mounten) zu können. Weil er so wichtig ist, werden Backup-Kopien dieses Blocks in mehreren Blockgruppen im Dateisystem angelegt. Die Informationen im Superblock enthalten Felder, die z. B. die Anzahl der Blöcke und Inodes im Dateisystem angeben, wie viele davon frei sind, wie viele Inodes und Blöcke in jeder Blockgruppe vorhanden sind, wann das Dateisystem eingebunden wurde, ob es beim letzten Mal auch wieder sauber ausgehangen wurde, wann es geändert wurde, welche Version vorliegt, und welches Betriebssystem es angelegt hat.Inodes
Der Inode (Index-Knoten) ist ein fundamentales Konzept im ext2-Dateisystem. Jedes Objekt im Dateisystem wird durch einen Inode repräsentiert. Die Inode-Struktur enthält Pointer auf die Blöcke, in denen die Daten des Objekts abgelegt sind, und außerdem alle Metadaten über ein Objekt mit Ausnahme seines Namens. Zu den Metadaten gehören Zugriffsrechte, Besitzer, Gruppe, Flags, Größe, die Anzahl der benutzten Blöcke, Zugriffszeitpunkt, Änderungszeitpunkt, Löschzeitpunkt, Anzahl der Links, Fragmente, Version (wird von NFS benötigt), erweiterte Attribute und eventuelle Zugriffskontrollisten (ACLs).Verzeichnisse
Ein Verzeichnis ist ein Dateisystem-Objekt und hat wie eine normale Datei einen Inode. Prinzipiell ist es eine spezielle Datei, die jeden Dateinamen im Verzeichnis mit einer Inode-Nummer verknüpft. Neuere Versionen des Dateisytems legen auch den Typ des Objektes (Datei, Verzeichnis, Symlink, Gerät, FIFO, Socket) mit ab, um zu vermeiden, dass der Inode selbst auf diese Information geprüft werden muss (um dies nutzen zu können, ist eine neuere Version der glibc erforderlich)
Spezielle Dateien
Symbolische Links (Symlinks) sind ebenfalls Dateisystem-Objekte mit Inodes. Wenn der Symlink allerdings kürzer als 60 Bytes ist, werden seine Daten direkt im Inode gespeichert. Dabei werden Felder benutzt, die normalerweise Pointer auf Datenblöcke halten würden. Da die meisten Symlinks weniger als 60 Zeichen lang sind, spart man hierdurch die die Inanspruchnahme eines Blocks für den Symlink.Reservierter Speicherplatz
Innerhalb des Dateisystems lässt sich eine bestimmte Anzahl von Blöcken für einen bestimmten Benutzer (normalerweise den Superuser root. Dies erlaubt dem System, auch dann zu funktionieren, wenn nicht privilegierte Benutzer den gesamten Ihnen zur Verfügung stehenden Speicherplatz aufgefüllt haben. Der Mechanismus funktioniert unabhängig von Dateisystem-Quotas. Weiterhin hilft er dabei, ein vollständiges Füllen des Dateisystems zu verhindern und so Fragmentierung zu bekämpfen.Dateisystem-Überprüfung
Während der Startphase führen die meisten Systeme einen Konsistenz-Check (e2fsck) auf ihren Dateisystemen durch. Der Superblock des ext2-Systems enthält mehrere Felder, die anzeigen, ob fsck laufen sollte (da die Prüfung des Dateisystems lange dauern kann, wenn es sehr groß ist). fsck wird üblicherweise laufen, wenn das Dateisystem nicht sauber ausgehangen wurde oder eine einstellbare Maximalzeit zwischen zwei Routine-Checks überschritten wurde.Feature-Kompatibilität
ext2 verfügt über einen ausgreiften Kompatibilitätsmechanismus, der es erlaubt, Dateisysteme unter Kernels zu verwenden, deren ext2fs-Treiber von einigen verwendeten Funktionen nichts weiß. Der Kompatibilitätsmechanismus steht seit ext2fs Revision 1 zur Verfügung. Es gibt dabei drei Felder von je 32 Bit Länge, eines für kompatible Features (COMPAT), eines für nur lesekompatible Features (RO_COMPAT) und eines für inkompatible Features (INCOMPAT).Dateisystem-Limits
{| border="1" cellpadding="5" cellspacing="0" align="right" style="margin-left:0.5em;"
|-
!align="left" | Blockgröße:
!1 kB
!2 kB
!4 kB
!8 kB
|-
!align="left" | max. Dateigröße:
|16 GB
|256 GB
|2048 GB
|2048 GB
|-
!align="left" | max. Dateisystemgröße:
|2047 GB
|8192 GB
|16384 GB
|32768 GB
|-
|+align="bottom" | Datei(system)limits des ext2-Dateisystems auf Linux
|}
Die Ursachen für gewisse Limits des ext2-Dateisystems können einerseits im Datenformat auf dem Datenträger begründet sein, andererseits durch den Kernel des zugrunde liegenden Betriebssystems. Die meisten werden einmalig bei der Erstellung des Dateisystems festgelegt und hängen von der gewählten Blockgröße und dem gewählten Verhältnis von Blöcken zu Inodes ab.
Die in der nebenstehenden Tabelle genannten Limits für Dateigrößen haben eher akademischen Wert, da zum Beispiel der Linux-Kernel 2.4 keine Dateien > 2 GB zulässt, und Blockgrößen von 8 kB sind standardmäßig nur auf Alpha-Architekturen möglich, sowie auf speziell konfigurierten und gepatchten anderen Architekturen.ext3
Journaling mit ext3fs
Die von Stephen Tweedie entwickelte Journaling-Erweiterung für ext2 sorgt dafür, dass Metadaten nicht mehr korrumpiert werden können, und dass auf einen kompletten Durchlauf von e2fsck nach einem Rechnerabsturz verzichtet werden kann. Ein solches Dateisystem wird meist als ext3-Dateisystem bezeichnet. Das Datenformat auf der Disk ändert sich bei Verwendung eines Journals nicht. Das Journal ist eine reguläre Datei, in die die Metadaten (optional auch die Nutzdaten) geschrieben werden, bevor sie auf das tatsächliche Dateisystem geschrieben werden. Aus einem ext2- kann man daher ein ext3-Dateisystem machen, ohne irgendwelche Daten konvertieren zu müssen.
