Seite 2: "Aufbau"

Inhaltsverzeichnis

Simpel

Wie jedes ordentliche Unix-Dateisystem arbeitet Ext3 im Wesentlichen mit drei Datenstrukturen: Verzeichnisse, Inodes und Datenblöcke. Verzeichnisse enthalten neben den Namen der Dateien nur noch die Nummern der ihnen zugeordneten Inodes. Dabei können durchaus mehrere Directory-Einträge auf einen Inode verweisen (harte Links). Auf der Platte sind Verzeichnisse als Dateien abgelegt, die sich lediglich durch den Dateityp (und ihren festgelegten Aufbau) von regulären Dateien unterscheiden.

Inodes speichern mit Ausnahme des Namens alles, was man über eine Datei wissen muss: Größe, Dateityp (reguläre Datei, Verzeichnis, Gerätedatei, Pipe, Socket oder symbolischer Link), Besitzer, Anzahl der harten Links, Zugriffsrechte und -zeiten – und die Nummern der Datenblöcke, die die Daten enthalten. Diese Informationen (mit Ausnahme der Nummern der Datenblöcke) lassen sich mit dem Tool stat, viele davon auch mit ls erfragen. Die ls-Option -i gibt die Inode- Nummer einer Datei aus.

Inodes sind in Tabellen gespeichert, die mke2fs in reservierten Bereichen des Dateisystems anlegt. Bei symbolischen Links, deren Name nicht länger als 60 Zeichen ist, wird auch der Name direkt im Inode abgelegt – an Stelle der maximal 15 Blocknummern von jeweils 4 Byte (so genannte schnelle symbolische Links). Ansonsten ist der Name der Datei, auf die der Symlink verweist, in der Datei gespeichert, die der Inode repräsentiert.

Datenblöcke schließlich speichern die eigentlichen Daten. Sie fassen mehrere Sektoren von 512 Byte (die kleinste adressierbare Einheit auf Festplatten) zusammen. Ext3 arbeitet mit Blockgrößen von 1024, 2048 oder 4096 Byte – welche bei einem Dateisystem zum Einsatz kommt, legt der Ext3-Formatierer mke2fs beim Anlegen des Dateisystems fest. Theoretisch unterstützt Ext3 Blockgrößen bis zu 64 KByte, auf der x86- und x64-Architektur ist bei 4 KByte allerdings Schluss: Dann sind die Blöcke im Dateisystem gerade so groß wie die Speicherseiten des Kernels im RAM, was dem Betriebssystem das Paging erleichtert.

Große Blöcke vereinfachen das Verwalten des Datenbestandes und erlauben größere Dateisysteme: Ext3 verwendet 32-Bit- Werte zum Durchnummerieren der Blöcke, kann also nur gut vier Milliarden Blöcke – 4 TByte bei einer Blockgröße von 1024 Byte, 16 TByte bei 4096 Byte – adressieren. Zudem belegen die Verwaltungsstrukturen des Dateisystems bei kleinen Blockgrößen einen größeren Anteil des Platzes auf der Festplatte.

Andererseits können große Blöcke eine Menge Plattenplatz verschwenden, da Dateien immer ganze Blöcke belegen, auch wenn sie nur wenige Byte enthalten: Im Schnitt verplempert jede Datei einen halben Block – je größer die Blöcke und je kleiner die Dateien, desto mehr fällt diese so genannte interne Fragmentierung ins Gewicht. Ext3 enthält zwar schon Datenstrukturen zur Verwaltung mehrerer Fragmente in einem Datenblock (Fragmente meint in diesem Zusammenhang Dateireste, die keine ganzen Blöcke belegen); das Feature ist allerdings nicht implementiert, auch wenn mke2fs dafür bereits den Parameter -f vorsieht.

Beim Formatieren wählt mke2fs die Blockgröße entsprechend der Größe des Dateisystems: 1 KByte bei bis zu 512 MByte, ansonsten 4 KByte. Mit der mke2fs-Option -b lässt sich die Blockgröße aber auch von Hand festlegen – das kann sinnvoll sein, wenn auf einem Dateisystem fast nur sehr kleine Dateien gespeichert werden sollen und es einem um den bei größeren Blöcken verschwendeten Platz leidtut.

Schnell

Der ganze Aufbau von Ext3 ist auf das optimiert, was Anwendungen normalerweise tun: Daten aus einer Datei mit einem bestimmten Namen lesen oder in eine solche Datei hineinschreiben. Für das Dateisystem heißt das, es muss sehr schnell die Daten finden, die zu einem Dateinamen gehören. Dreh- und Angelpunkt dabei sind die über den Directory-Eintrag erreichbaren Inodes mit Metadaten und Verweisen auf die Datenblöcke. Der Weg rückwärts ist nicht möglich: Um herauszufinden, zu welcher Datei ein bestimmter Datenblock gehört, müssen zunächst alle Inodes auf die angefragte Blocknummer und dann die Verzeichnisse nach dieser Inode-Nummer durchsucht werden. Das Low-level-Werkzeug debugfs erledigt das mit den Befehlen icheck und ncheck (siehe Textkasten Dateisystem-Debugger).

Der Zugriff auf die Inodes muss daher besonders effizient erfolgen. Das wird unter anderem dadurch sichergestellt, dass die Inodes bereits bei der Formatierung als statische Tabellen auf die Platte geschrieben werden. Eine Konsequenz davon ist, dass sich die Zahl der Inodes nach dem Anlegen des Dateisystems nicht mehr verändern lässt. Da jeder Datei ein eindeutiger Inode zugeordnet sein muss, kann es nicht mehr Dateien als Inodes geben. mke2fs legt standardmäßig einen Inode pro 4 KByte bei Dateisystemen bis 512 MByte an, ansonsten einen Inode pro 8 KByte.

Wer glaubt, dass er es besser weiß als mke2fs, weil er nur wenige große oder sehr viele kleine Dateien speichern will, kann beim Aufruf von mke2fs mit der Option -i einen beliebigen Wert vorgeben, für wie viele Byte Daten jeweils ein Inode benötigt wird. Bei wenigen Inodes kann man weniger Dateien anlegen, schlägt aber einige Megabyte mehr nutzbaren Plattenplatz heraus – immerhin belegt jeder Inode standardmäßig 128 Byte auf der Platte. Viele Inodes erlauben das Anlegen von mehr Dateien.

Über die mke2fs-Option -T Typ kann man auch auf einige in /etc/mke2fs.conf vordefinierte Einstellungen zugreifen: small (Default bei Dateisystemen bis 512 MByte) wählt eine Blockgröße von 1 KByte bei einem Inode pro vier Blöcken, news eine Blockgröße von 4 KByte mit einem Inode pro Block, largefile und largefile4 stehen für einen Inode pro 256 und 1024 Blöcken bei einer Blockgröße von 4 KByte.

Auch die feste Größe der Inodes von 128 Byte erlaubt einen schnellen Zugriff auf diese zentrale Datenstruktur. Mit

mke2fs -I Inode-Größe

kann man beim Anlegen des Dateisystems einen größeren Wert vorgeben, wobei der Wert glatt durch 128 teilbar sein muss. In größeren Inodes kann Ext3 erweiterte Attribute ablegen (siehe c’t 23/03, S. 218).