| ext2 | |
|---|---|
| Hersteller | Rémy Card |
| Vollständige Bezeichnung | Second extended file system |
| Erstveröffentlichung | Januar 1993 (Linux) |
| Partitionskennung | Apple_UNIX_SVR2 (Apple Partition Map) 0x83 (Master Boot Record) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT) |
| Technische Umsetzung | |
| Dateien | Inode |
| Maximalwerte | |
| Größe einer Datei | 2 TiB |
| Anzahl aller Dateien | 1018 |
| Länge des Dateinamens | 255 Byte |
| Größe des Dateisystems | 16 TiB |
| Erlaubte Zeichen im Dateinamen | Alle Zeichen außer NUL und / |
| Eigenschaften | |
| Datumsbereich | 1901-12-13 20:45:52 bis 2038-01-19 03:14:07 (UTC+0) (vgl. Jahr-2038-Problem) |
| Forks | unterstützt |
| Dateirechte-Verwaltung | POSIX |
| Transparente Komprimierung | optional (s. u.) |
| Transparente Verschlüsselung | nein |
| Unterstützende Betriebssysteme | Linux, BSD, Mac OS X, Windows (durch ext2 File System Driver[1] oder Ext2 IFS[2]) |
Das second extended filesystem, oder kurz ext2, ist das zweite extended filesystem für Linux-Betriebssysteme. Es folgt auf das ursprüngliche ext-Dateisystem, das 1993 von Rémy Card auf Basis des Minix-Dateisystems entwickelt wurde. Die originale Implementierung im Linux-Kernel stammt sowohl von ihm als auch von Theodore Ts’o und Stephen Tweedie; sie wurde mit Kernel 6.9 vom 12. Mai 2024 als veraltet (englisch deprecated) markiert.[3] ext2 war viele Jahre das Standard-Dateisystem vieler Linux-Distributionen und wurde schließlich durch modernere Journaling-Dateisysteme ersetzt. Die Nachfolger von ext2 sind ext3 bzw. ext4, von denen es großteils abgelöst wurde. Der ext4-Dateisystemtreiber von Linux kann auch mit ext2 umgehen.
Neben dem Quelltext im Linux-Kernel, der unter der GPLv2 steht, existieren Implementierungen für AmigaOS, FreeBSD, GNU Hurd, Mac OS X, MiNT, MorphOS, NetBSD, OpenBSD, OS/2, RISC OS und Windows unter verschiedenen Lizenzen.
ext2 teilt viele seiner Eigenschaften mit traditionellen Unix-Filesystemen, etwa das Konzept der Blöcke, Inodes und Verzeichnisse. Wenn gewünscht, ist es um Eigenschaften wie Zugriffskontrolllisten, 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 in einem ext2-Dateisystem werden immer im Little-Endian-Format abgelegt, so kann es sowohl auf Little- als auch auf Big-Endian-Architekturen eingehängt werden, ohne dass es zu Inkompatibilitäten kommt.
Der Platz auf einer mit ext2 formatierten Partition wird in Blöcke aufgeteilt. Diese haben eine feste Größe von 1 KiB, 2 KiB oder 4 KiB, auf Alpha-Prozessoren sind zudem Blockgrößen von 8 KiB möglich. 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 jedoch mehr Zusatzaufwand bei der Verwaltung, und begrenzen indirekt die maximale Größe der Dateien und des ganzen Dateisystems.
Um eine Fragmentierung von vornherein weitestgehend zu vermeiden, die den Zugriff auf große Mengen aufeinander folgender Blöcke bremsen würde, werden Blöcke in Blockgruppen zusammengefasst. Die Informationen über jede Blockgruppe werden in einer Deskriptortabelle abgelegt, die direkt hinter dem Superblock liegt. Zwei Blöcke in der Nähe des Anfangs der Blockgruppe sind für zwei Bitmaps reserviert, welche die Block- und Inode-Belegung in der Gruppe anzeigen. Da jede Bitmap nur einen Block belegen kann, ist die maximale Größe jeder Blockgruppe (in Blöcken) auf achtmal die Größe eines Blockes (in Bytes) begrenzt. Die auf die Bitmaps folgenden Blöcke enthalten die Inode-Tabelle für die Blockgruppe, und die übrigen sind als Datenblöcke nutzbar.
Der Superblock enthält alle Informationen über die Konfiguration des Dateisystems. Der primäre Superblock liegt 1024 Byte hinter dem Anfang des Gerätes und ist wichtig, um das Dateisystem einbinden (mounten) zu können. Die Informationen im Superblock enthalten Felder, die zum Beispiel 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 korrekt ausgehängt wurde, wann es geändert wurde, welche Version vorliegt, und welches Betriebssystem es angelegt hat. Da bei einer Beschädigung des Superblocks das gesamte Dateisystem unbrauchbar wäre, werden vom Superblock mehrere Kopien, verteilt in mehreren Blockgruppen, gespeichert. Diese Superblock-Kopien erlauben im Fehlerfall eine Reparatur des Original-Superblocks.
Wenn das Dateisystem Revision 1 oder neuer ist, gibt es im Superblock weitere Felder, die den Namen des Datenträgers, eine eindeutige Identifikationsnummer und die Inode-Größe angeben, sowie Platz für die Konfigurationsinformationen optionaler Dateisystemfunktionen bieten.
Der Inode (Indexknoten) ist ein fundamentales Konzept im ext2-Dateisystem. Jedes Objekt im Dateisystem wird durch einen Inode repräsentiert. Die Inode-Struktur enthält Zeiger (Verweise) 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 Verknüpfungen, Fragmente, Version (wird von NFS benötigt), erweiterte Attribute und eventuelle Zugriffskontrolllisten.
Es gibt einige ungenutzte Felder und überladene Felder in der Inode-Struktur. Ein Feld ist für die Verzeichnis-Zugriffskontrollliste 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 über 2 GiB). Die meisten der übrigen Felder werden von Linux und GNU Hurd als vergrößerte Besitzer- und Gruppenfelder genutzt. GNU 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 Zeiger auf die ersten 12 Blöcke, welche die Daten der Datei enthalten. Außerdem gibt es einen Zeiger auf einen indirekten Block (der wiederum Zeiger auf den nächsten Satz von Blöcken der Datei enthält), einen Zeiger auf einen doppelt indirekten Block (der Zeiger auf weitere indirekte Blöcke enthält), und einen Zeiger auf einen dreifach indirekten Block (der Zeiger auf doppelt indirekte Blöcke enthält).
Das Flags-Feld enthält einige ext2-spezifische Flags, die nicht beispielsweise durch chmod beeinflusst werden können. Diese Flags können mit dem Programm lsattr gelistet werden und mit chattr geändert werden. Diese Flags erlauben einer Datei besonderes Verhalten, welches über die POSIX-Dateiflags nicht darstellbar ist: Es gibt Flags für sicheres Löschen, Unlöschbarkeit, Kompression, synchrone Updates, Schreibschutz, indizierte Verzeichnisse, Journaling und einiges mehr. Die Attribute eines Verzeichnisses werden auf neu erzeugte darunterliegende Dateien vererbt.
Nicht alle Flags werden jedoch vom ext2-Treiber im Kernel umgesetzt: das Attribut „c“ (komprimieren) wird beispielsweise von der ext2-implementation des Linux-Kernels nicht unterstützt. Dafür gab es das inzwischen eingestellte extz-Projekt (= ext3 + Kompression + Verschlüsselung).
Ein Verzeichnis ist ein Dateisystemobjekt 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 Dateisystems legen zudem den Typ des Objektes (Datei, Verzeichnis, symbolische Verknüpfung, 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).
Ein im Verzeichnis eingetragener Dateiname wird als Verknüpfung oder Harter Link bezeichnet, wenn die Abgrenzung gegenüber einer symbolischen Verknüpfung betont werden soll. Dahinter steckt eine „N zu 1“-Beziehung zwischen Verknüpfungen und Dateien. Die Datei, die aus den Nutzdaten und dem Inode besteht, wird erst über einen Dateipfad, also einen Verzeichniseintrag nutzbar. Da zu einer Datei beliebig viele Verzeichniseinträge angelegt werden können, ist es sinnvoll, diese nicht mit der Datei zu identifizieren, sondern als „Verweise“ auf die Datei zu begreifen. Mehrere Verknüpfungen zu einer Datei können im selben Verzeichnis stehen. Im Inode der Datei wird über die Anzahl der Verknüpfungen Buch geführt. Nach dem Löschen der letzten Verknüpfung einer Datei wird die Datei selbst, also der Inode und die Nutzdatenblöcke, freigegeben.
Beim Erzeugen einer neuen Verzeichnisdatei werden gleich zwei Verknüpfungen dazu eingerichtet: Einer im übergeordneten Verzeichnis mit dem gewählten Verzeichnisnamen und einer mit dem Namen „.“ im neuen Verzeichnis selbst. Unterverzeichnisse haben jeweils noch eine Verknüpfung namens „..“ auf die übergeordnete Verzeichnisdatei. Für das Wurzelverzeichnis eines Dateisystems sind die beiden Verknüpfungen „.“ und „..“ identisch.
Symbolische Verknüpfungen (Symlinks) sind ebenfalls Dateisystemobjekte mit Inodes. Wenn die Verknüpfung jedoch kürzer als 60 Bytes ist, werden ihre Daten direkt im Inode gespeichert. Dabei werden Felder benutzt, die normalerweise Zeiger auf Datenblöcke halten würden. Da die meisten Verknüpfungen weniger als 60 Zeichen lang sind, werden hierdurch die Inanspruchnahme eines Blocks für die symbolische Verknüpfung gespart. Symbolische Verknüpfungen können über Dateisystemgrenzen (also ebenfalls über mehrere Festplatten oder Partitionen) hinweg eingesetzt werden. Dabei kann es passieren, dass die Datei, auf die die symbolische Verknüpfung verweist, gelöscht wird, die Verknüpfung jedoch bestehen bleibt. Die Verknüpfung verweist damit auf eine nicht mehr vorhandene Datei und ist somit unbrauchbar geworden.
Zeichen- und blockorientierten Geräten sind nie Datenblöcke zugewiesen. Stattdessen wird die vom Kernel vergebene Gerätenummer im Inode abgelegt, wobei wiederum die Zeigerfelder auf Datenblöcke benutzt werden.
Innerhalb des Dateisystems lässt sich eine bestimmte Anzahl von Blöcken für einen bestimmten Benutzer reservieren, normalerweise für den Systemadministrator root. Dies erlaubt dem System, auch dann zu funktionieren, wenn nichtprivilegierte Benutzer den gesamten ihnen zur Verfügung stehenden Speicherplatz aufgefüllt haben. Der Mechanismus funktioniert unabhängig von Disk Quotas. Weiterhin hilft er dabei, ein vollständiges Füllen des Dateisystems zu verhindern und so Fragmentierung zu bekämpfen.
Während der Startphase führen die meisten Systeme eine Konsistenzüberprüfung (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 ausgehängt wurde oder eine einstellbare Maximalzeit zwischen zwei Routineüberprüfungen überschritten wurde.
ext2 verfügt über einen ausgereiften 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 Eigenschaften (COMPAT), eines für nur lesekompatible Features (RO_COMPAT) und eines für inkompatible Eigenschaften (INCOMPAT).
Ein COMPAT-flag bedeutet, dass das Dateisystem eine Eigenschaft 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 anschließend ohne Benutzung des Journals darauf schreiben, ohne irgendetwas zu beschädigen.
Ein RO_COMPAT-flag zeigt an, dass das Datenformat des Dateisystems beim Lesen 100 % kompatibel zu ä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 eine lesekompatible Eigenschaft ist SPARSE_SUPER, ein Dateisystemlayout, bei dem weniger Superblocksicherungen 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 eventuell die Bitmaps inkonsistent werden.
Ein INCOMPAT-flag zeigt an, dass sich das Datenformat so geändert hat, dass Kernel ohne diese Eigenschaft weder schreiben noch lesen oder auch nur einhängen könnten. Als Beispiel für eine inkompatible Zusatzfunktion kann die optionale Kompression dienen; ein Kernel, der die Daten nicht dekomprimieren kann, würde nur „Müll“ vom Datenträger lesen. Auch ein inkonsistentes ext3-Dateisystem ist so lange inkompatibel, bis ein ext3-fähiger Kernel das Journal gelesen und die Inkonsistenzen beseitigt hat. Danach kann das ext3-System wieder als ext2 eingehängt werden.
Das Hinzufügen neuer Eigenschaften zum ext2/3-Dateisystem erfordert immer eine Aktualisierung des zugehörigen toolkit e2fsprogs, da die darin enthaltenen Prüfungswerkzeuge in der Lage sein müssen, alle Dateisystemeigenschaften zu kennen, um eine zuverlässige Feststellung und Behebung von Inkonsistenzen zu ermöglichen.
| Blockgröße: | 1 KiB[4] | 2 KiB | 4 KiB | 8 KiB |
|---|---|---|---|---|
| max. Dateigröße: | 16 GiB | 256 GiB | 1 TiB | 2 TiB |
| max. Dateisystemgröße: | 4 TiB | 8 TiB | 16 TiB | 32 TiB |
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. Blockgrößen von 8 KiB sind standardmäßig nur auf Alpha-Architekturen möglich sowie auf speziell konfigurierten und gepatchten anderen Architekturen. Unabhängig von den Fähigkeiten des Kernels können einige Userspace-Programme, denen Unterstützung für große Dateien fehlt, Dateien jenseits von 2 GiB nicht korrekt handhaben.
Das Dateisystem begrenzt die Anzahl von Unterverzeichnissen in einem gegebenen Verzeichnis auf 32.000 Stück. Weiterhin wird angewarnt, wenn in einem Verzeichnis mehr als etwa 10.000 bis 15.000 Dateien liegen, dass Dateioperationen in solch großen Verzeichnissen lange dauern könnten. Die tatsächlich maximal mögliche Anzahl von Dateien ist akademischer Natur, da es bereits schwierig sein wird, genügend Dateinamen zu erzeugen, bevor das Limit von 130 Trillionen (1018) Dateien pro Verzeichnis erreicht wird.