Seite 3: "Indirekte Adressierung"

Inhaltsverzeichnis

Indirekt

Aber wie kriegt man in einer statischen Datenstruktur von 128 Byte die Nummern der Millionen Datenblöcke unter, die man für gigabytegroße Dateien braucht? Gar nicht – ein Ext3-Inode speichert genau 15 Blocknummern. Die ersten zwölf verweisen direkt auf Datenblöcke, Block 13 auf einen Datenblock mit Blocknummern (indirekt adressierte Blöcke), Block 14 auf einen Block, der auf Blöcke mit Blocknummern verweist (doppelt indirekt), und Block 15 verweist auf dreifach indirekt adressierte Blöcke. Damit kann ein Inode bei 4 KByte Blockgröße (also 1024 Blocknummern à 4 Byte in einem indirekten Block) 12 + 1024 + 1024² + 1024³, also gut eine Milliarde Blocknummern verwalten.

Die daraus resultierende maximale Dateigröße von etwas über 4 TByte ist allerdings ein theoretischer Wert, da die Inodes die Anzahl der zu einer Datei gehörenden Festplattensektoren 512 Byte speichern – stat und der stat-Befehl in debugfs geben diesen Wert als Blockcount aus. Da es sich dabei um einen 32-Bit-Wert handelt, liegt die maximale Dateigröße von Ext3 bei 2 TByte.

Die 2-GByte-Grenze, mit der sich manche alten Anwendungen bei der Dateigröße herumschlagen, ist übrigens nicht in Ext3 begründet, sondern in den System-Calls zum Zugriff auf Dateien. Die Funktionen und Datenstrukturen zum Zugriff auf Dateien arbeiten traditionell mit einem vorzeichenbehafteten 32-bittigen File Offset (ein Zeiger, der jedes beliebige Byte innerhalb einer Datei adressieren kann), was lediglich eine Dateigröße von 2³¹-1 Byte zulässt. Diese Grenze ist aber längst gefallen: Large File Support (LFS) heißt das Zauberwort (s. c't 10/00, S. 256).

Gruppiert

Neben den Directories, den Inode-Tabellen und den Datenblöcken selbst arbeitet Ext3 noch mit einigen weiteren Datenstrukturen. Zwei Bitmaps führen Buch darüber, welche Datenblöcke und Inodes belegt und welche frei sind. Um auch hier für Effizienz beim Zugriff zu sorgen, organisiert Ext3 das Dateisystem in Blockgruppen – eine Art Partitionierung innerhalb des Dateisystems.

Beim Lesen, Schreiben und Anlegen von Dateien hüpfen die Festplattenköpfe nämlich munter zwischen Datenblöcken, Verzeichnissen, Inode-Tabelle sowie Inode- und Block-Bitmap hin und her. Nun brauchen Bewegungen der Plattenköpfe aber im Schnitt mehrere Millisekunden – in dieser Zeit kann man von einer schnellen Platte auch ein Megabyte an Daten lesen. Unter der Annahme, dass Kopfbewegungen umso länger dauern, je weiter die entsprechenden Sektoren auf der Platte auseinanderliegen, ist es vorteilhaft, zusammengehörende Teile der Verwaltungsstrukturen und Daten nahe beieinander zu speichern.

Das macht Ext3 mit den Blockgruppen: Jede Blockgruppe enthält (neben einem Block Group Descriptor mit einigen statistischen Angaben, wie sehr diese Blockgruppe bereits genutzt ist) einen Teil der Inode-Tabelle sowie den Teil der Inode- und Block-Bitmap, der diesen Ausschnitt der Inode-Tabelle und die Datenblöcke der Blockgruppe abbildet. Ext3 bemüht sich, Dateien so anzulegen, dass Verwaltungsstrukturen – Inode und Verzeichnis – und Datenblöcke innerhalb einer Blockgruppe liegen.

Die Anzahl der angelegten Blockgruppen ist abhängig von der Größe des Dateisystems. Der Parameter lässt sich zwar mit der mke2fs-Option -g setzen, die Ext3-Entwickler raten allerdings davon ab, da mke2fs bereits den optimalen Wert wählt. Da für die Block-Bitmap der Blockgruppe bloß ein Datenblock vorgesehen ist, kann eine Blockgruppe bei einer Blockgröße von 4 KByte maximal 32 768 Blöcke, also 128 MByte enthalten.