Logische und physikalische Struktur des Second Extended Filesystem für Linux

Seminar Paper , 2000 , 18 Pages , Grade: ohne

Computer Science - Theory

INHALTSVERZEICHNIS

1. EINLEITUNG UND MOTIVATION

2. TECHNISCHER ANSATZ

3. MULTITALLENT LINUX

4. SECOND EXTENDED FILESYSTEM
4.1 Physikalische Struktur
4.1.1 Bootblock
4.1.2 Superblock
4.1.3 Blockgruppenbeschreibung
4.1.4 Datenblockbitmap und Inodebitmap
4.1.5 Inodes und Inodeliste
4.1.6 Datenblöcke
4.2 Logische Struktur
4.2.1 Reservierte Inodes
4.2.2 Dateitypen
4.2.2.1 Verzeichnisse
4.2.2.2 Links (Verweise)
4.2.3 Dateitabellen
4.2.4 File System Check

5. VIRTUELLES DATEISYSTEM (VFS)

6. LEISTUNGSBEWERTUNG UND GRENZEN VON EXT2FS
6.1 Datenrettung für Abenteurer
6.2 Große Dateien
6.3 Sparse Files

7. AUSBLICK

8. ZUSAMMENFASSUNG

9. LITERATUREMPFEHLUNGEN

10. REFERENZEN

11. ANHANG

ÜBERSICHT

Dateisysteme (Filesystems, fs) erfüllen den Zweck der persistenten Datensicherung. Ihre Aufgabe ist es, Mecha- nismen zur Verfügung zu stellen, die es ermöglichen, Daten in problembezogenen Einheiten (Dateien, files) über das Terminieren eines Prozesses und sogar über das Abschalten eines Rechners hinaus bewahren zu können. Im folgenden werden die Aufgaben und Funktionen eines Dateisystems näher betrachtet und eine Auswahl an mög- lichen Dateisystemen für Linux vorgestellt. Daran schließt sich eine nähere Betrachtung des ext2 Filesystems an - das Dateisystem, welches wohl am häufigsten in Linuxsyste- men zum Einsatz kommt. Wie die Dateisysteme im Be- triebssystem integriert sind, zeigt die Vorstellung der Konzeption des Virtuellen Dateisystems (virtual filesy- stem, VFS), die diese Arbeit abschließt.

1. EINLEITUNG UND MOTIVATION

Auf der Suche nach Sinn und Zweck eines Dateisystems kommt man an der Frage nach einer Begriffserklärung nicht vorbei. J. L. Keedy¹ hält dafür eine Definition bereit:

"Ein Dateiverwaltungssystem (Dateisystem, file manage- ment, file system) ist die Komponente eines Betriebssy- stems, die den Speicherplatz auf externen Datenträgern für die Haltung von Dateien organisiert und die Funktionen für das Speichern, Ändern und Wiedergewinnen von Da- teien bereitstellt."

Daraus lassen sich einige Aufgaben eines Dateisystems ableiten. Ein Dateisystem verwaltet die externen Datenträ- ger eines Systems sowohl logisch als auch physikalisch. Logisch: Es wird eine abstrakte Sicht auf den Datenträger geschaffen. D.h. Dateien werden mit Namen qualifiziert und die Kenntnis der genauen physikalischen Lage auf dem Datenträger ist für Programme außerhalb der Dateisystemkomponente des Betriebsystemkernels nicht von Nöten. Zur Strukturierung der Daten (sowohl Systemdaten als auch Benutzerdaten) bieten wohl aus- nahmslos alle Dateisysteme die Möglichkeit zur Organisa- tion in einer Baumstruktur. Dadurch wird das Auffinden von gespeicherten Daten für den Benutzer übersichtlicher und weniger aufwendig. Dies wird durch den Einsatz von Verzeichnissen erreicht. Dazu hat das Dateisystem ein sogenanntes Wurzelverzeichnis, welches als Urahn aller Verzeichnisse anzusehen ist. Verzeichnisse können dann Dateien oder wiederum Verzeichnisse beinhalten.

Physikalisch: Zur Verwaltung der logischen Struktur muß das Dateisystem eine Struktur auf dem Datenträger anle- gen, welche das Lesen/Schreiben und Wiederauffinden von Daten möglichst effizient erlaubt. Außerdem ist eine Struktur wünschenswert, die einen Verlust von Verwal- tungsinformationen (z.B. durch Hardwaredefekt) nicht gleich zum Daten-GAU werden läßt. Diese geforderte Redundanz sollte aber das Arbeiten mit den Daten nicht allzusehr bremsen.

Eine weitere nicht zu verachtende Aufgabe des Dateisystems ist das automatische Erkennen von defekten Stellen (Sektoren) auf der Datenträgeroberfläche, und deren Sperrung für weitere Benutzung, da ansonsten der Datenverlust schon vorprogrammiert ist.

Nicht allgemein erforderlich, aber für Dateisysteme, die in Mehrbenutzerbetrieb (z.B. in Netzwerken) eingesetzt wer- den unabdingbar, ist die Bereitstellung von Sicherheitsme- chanismen. Benutzer sollten ihre eigenen Daten vor den Blicken anderer Benutzer, oder Benutzern anderer Benut- zergruppen schützen können. Bei Bedarf können dann für bestimmte Daten immer noch verschiedene Rechte verge- ben können (z.B. nur lesender Zugriff erlaubt).

2. TECHNISCHER ANSATZ

Die Daten in einem Dateisystem werden nicht, wie man dies von der Speicherverwaltung im Hauptspeicher eines Rechners kennt, auf Byte- oder Wortebene adressiert, sondern unter Zuhilfenahme einer Blockstruktur. Blöcke sind Speichereinheiten fester Größe. Die Anzahl der Bytes, welche in einem Block gespeichert werden können, ist durch den Controller des Datenträgers festgelegt. Bei Festplatten hat ein solcher physikalischer Block meist 512 Byte. Daten werden mit den Blocknummern der informa- tionstragenden Blöcke adressiert - diese Art der Adressie- rung nennt man Blockadressierung. Die Blöcke eines Da- teisystems lassen sich linear durchnummerieren und so eindeutig bestimmen. Die Umsetzung der Blocknummer

zur physikalischen Ortsbestimmung wird durch den Con- troller erledigt:

Block b; b ∈{0,1,...,(n-1)} Æ <#vol, #cyl, #head, #sector>

Somit ist eine Blocknummer eine zwar kodierte aber ein- deutige Positionsbeschreibung. Üblicherweise fassen Da- teisysteme mehrere physikalische Blöcke zu einem größe- ren logischen Block zusammen, welcher aus mehreren direkt aufeinander folgenden Blöcken besteht. Dies dient zur Verringerung des Verwaltungsaufwands bei den Blök- ken größerer Dateien. Spricht man von einem Block, so ist damit, falls nicht genauer bestimmt, immer der Begriff des logischen Blockes gemeint. Für die meisten Dateisysteme bedeutet dies eine Blockgröße von 1.024, 2.048, 4.096 oder 8.192 Byte Größe. Das entspricht eher den Speicher- platzanforderungen moderner Systeme, außer man beab- sichtigt, eine signifikante Menge von sehr kleinen Dateien anzulegen, deren Länge unter der eines physikalischen Blockes liegt. Hierbei ist es wichtig zu wissen, daß ein Block immer nur einer Datei als Resource zugeordnet wird, unabhängig von der Anzahl der tatsächlichen genut- zen Bytes im allokierten Block. Im statistischen Mittel ergibt sich daraus ein Verschnitt von einem halben Block für den letzten referenzierten Block einer jeden Datei. Beabsichtigt man also, viele kleine Dateien im Datei- system unterzubringen, so ist man mit einer kleinen Blockgröße besser beraten, oder man archiviert die kleinen Dateien komprimiert oder nur verkettet in einer größeren Datei, um den sogenannten Clusterverschnitt zu minimie- ren. Unabhängig von der logischen Blockgröße eines Da- teisystems wird die Größe einer Datei in Byte immer mit einer Genauigkeit von physikalischen Blöcken (512 Byte) angegeben. Das ist nützlich, wenn man bedenkt, daß ein und dieselbe Datei in verschiedenen Konfigurationen des Dateisystems eine Varianz in der Größe aufweisen würde. Das ist aber schon dadurch unwahrscheinlich, da die meisten Dateisysteme die Dateigrößen nicht aufgrund der verbrauchten Blöcke berechnen, sondern im Datei- deskriptor einer jeden Datei die tatsächliche Dateigröße (aufs Byte genau) dokumentieren.

3. MULTITALLENT LINUX

Entstanden aus der Vorstellung, ein transparentes, flexibles Betriebssystem zu entwickeln, war den Linux Programmierern klar, daß die Benutzer von Linux nicht zum Einsatz eines bestimmten Dateisystems gezwungen werden sollten. Deshalb stellt Linux dem Anwender eine ganze Reihe von möglichen Dateisystemen zur Verfügung. Dies ist ein großer Schritt in Richtung Kompatibilität zu anderen Systemen. Aktuelle Linuxversionen unterstützen bis zu 40 verschiedene Dateisystemtypen. Darunter befinden sich sowohl Systeme aus der Entstehungszeit von UNIX (minix fs) als auch brandaktuelle Typen wie z.B. ext3fs, das als Betaversion in manchen Distributionen als Quelltext beiliegt. Im folgenden wird eine kleine Auswahl verschiedener unterstützter Dateisysteme kurz vorgestellt¹:

affs: (Atari Fast Filesystem) gestattet Linux lesenden

und schreibenden Zugriff auf Datenträger von Atarisystemen.

extfs: (Extended Filesystem) von Remy Card für Linux

entwickeltes Dateisystem basierend auf UNIX.

ext2fs: (Second Extended Filesystem) Weiterentwicklung des extfs. Wird weiter unten genauer vorgestellt².

hpfs: (High Performance Filesystem) bietet lesenden

Zugriff auf OS/2 Datenträger.

isofs: nach der ISO-Norm 9660 benannt - wird auf CD-ROMs verwendet.

minixfs: der Urahn der UNIX Dateisysteme wird auch heute noch von LINUX unterstützt.

msdosfs: wird von Mircosofts DOS für sowohl Festplatten als auch Disketten verwendet.

ncpfs: (Netware Core Protocol FS) läßt LINUX einen Client in Novell-Netzen emulieren.

nfs: (Network Filesystem) UNIX-typisches Datei-

system, welches mehrere Dateisysteme im Netz zu einem logischen Verzeichnisbaum verschmelzen kann.

proc: stellt nur ein PseudoFS dar. Mit Proc lassen sich die internen Daten des Kernels bequem abfragen (siehe

Gerätedateien). Wird aber ansonsten als normales Dateisystem behandelt.

smbfs: Das Samba Filesystem erlaubt bspw. den Einsatz eines LINUX-Servers in einem Windows-NT Netz.

sysvfs: ein weiteres Relikt aus alten UNIX-Tagen.

ufsfs: kommt vor allem bei SOLARIS Systemen zum Einsatz.

umsdos: Erweiterung, um msdosfs zu einem „vollwertigen“ LINUX Dateisystem zu machen.

vfat: benutzt eine virtuelle Dateizuordnungstabelle (vir- tual file allocation table). Wird bei Windows 95/98

eingesetzt.

reiserfs: Ursprünglich als Privatstudie von Hans Reiser entwickeltes Dateisystem, welches die Möglichkeit

eines Journals bietet (Erklärung weiter unten)³. Ist inzwischen stabil im Betrieb und alltagstauglich.

LINUX läßt den parallelen Betrieb aller unterstützter Da- teisystemtypen zu. Dabei bleibt es für den Benutzer / Be- nutzerprogramme transparent, welches Dateisystem auf dem gemounteten Datenträger verwendet wird. Diese Leistung erbringt das Virtuelle Dateisystem¹ (VFS), dessen Konzeption (wenn vielleicht auch unter anderem Namen) in den meisten UNIX Systemen Eingang gefunden hat. Aufgabe des im Kernel liegenden VFS ist es, als Interface Dateisystemtreibern einen Satz von Funk- tionen vorzuschreiben, die diese implementieren müssen. Erfolgt nun eine Anforderung einer Dateisystemoperation als System call an den Kernel so verweist das VFS den Aufruf an die entsprechende Funktion des Dateisystem- treibers, welcher für den Typ des angeforderten Datei- systems zuständig ist.

4. SECOND EXTENDED FILESYSTEM

4.1 Physikalische Struktur

Zunächst soll die physikalische Struktur des Second Ex- tended Filesystem (ext2fs) vorgestellt werden. Dabei wird darauf eingegangen, welche Bedeutung die aufeinander- folgenden Blöcke der Datenträgeroberfläche für das Ver- waltungslayer des Dateisystems haben.

Blockgruppe Bl..

Datenblöcke

Fig 4.1 physikalische Struktur von ext2fs

Abbildung in dieser Leseprobe nicht enthalten

Die Blöcke eines Dateisystems sind in oben gezeigte Struktur integriert (Fig.4.1). Der erste Block eines Da- teisystems ist der sogenannte Bootblock. Anschließend folgen Blockgruppen, deren Größe, wie sich später noch zeigen wird, durch die Länge der logischen Blöcke definiert ist. Diese füllen den gesamten zur Verfügung stehenden Platz. Sie beinhalten die in Fig.4.1 bezeichneten Elemente, die im folgenden näher beschrieben werden. Genaue Informationen über ein bestimmtes Dateisystem liefert das Programm debugfs auf Eingabe von stats eindeutige Nummer. Anhand dieser Angabe erkennt das Virtuelle Dateisystem, mit welchem Dateisystemtreiber die Datenträgerpartition bedient werden soll. Diese Num- mer ist nicht ganz unwichtig, auch wenn sie vielleicht nur dazu dient, daß ein Betriebssystem an ihr erkennt, daß es diesen Dateisystemtyp nicht beherrscht. Für ext2fs ist diese Nummer 0xEF53. Neben dieser Dateisystemnummer findet sich auch noch eine Nummer, die angibt, mit wel- chem Betriebssystem das vorliegende Dateisystem einge- richtet wurde. Diese Nummer ist für das jeweilige Be- triebssystem spezifisch und eindeutig.

Der Status des Dateisystems (die Werte hierfür sind “sau- ber ausgehängt” und “eventuell fehlerbehaftet” ) finden sich auch unter den vielen Informationen, die der Super- block beinhaltet. Beim Mounten des Dateisystems wird der Status auf “eventuell fehlerbehaftet” gesetzt. Wird das Dateisystem aus dem Zugriff des Kernels entlassen (Un- mount), wird der Status auf “sauber ausgehängt” gesetzt, sofern dies tatsächlich ohne Fehler vonstatten geht. Wird beim nächsten Mounten der Wert “eventuell fehlerbehaf- tet” gelesen (dies ist z.B. dann der Fall, wenn während des laufenden Betriebes die Stromversorgung ausfällt), so wird der Dateisystemcheck ausgeführt, der die Verwaltungsin- formationen auf Konsistenz prüft.¹

Schließlich läßt ein weiterer Eintrag in Superblock darauf schließen, nach welcher Verhaltensweise beim Auftreten eines Fehlers vorgegangen werden soll. Mögliche Werte sind hier: “nur Lesen gestattet”, “Kernelfehlermeldungen ausgeben”, ”Normales Verhalten”. Trotz dieser Menge an Informationen ist die Länge des Superblocks nur 72 Byte. Da er aber wie der Name schon sagt, einen ganzen Block verbraucht, ist der verbleibende Rest des Blockes unbelegt und wird mit Nullbytes aufgefüllt. Bei einer Blockgröße von 4 KByte liegen also 4.024 Byte brach (⁴ ).

Alle diese Eigenschaften finden sich in der Strukturdefini- tion /usr/include/linux/ext2_fs.h wieder.

4.1.3 Blockgruppenbeschreibung

An den Superblock schließt sich die Blockgruppenbesch- reibung an. Sie beinhaltet Daten, die die jeweilige Block- gruppe beschreiben. Es sind dies die Blockadressen der folgenden Datenblockbitmap, Inodebitmap und der Inode- liste. Weitere Informationen, die man hier findet, sind die Anzahl der freien Blöcke und Inodes in dieser Block- gruppe. Es existiert hier auch ein Counter, der die Anzahl der Dateien zählt, die Verzeichnisse darstellen. Dies wird dazu verwendet, ein Verzeichnis immer in der Block- gruppe anzulegen, welche die wenigsten Verzeichnisse verwaltet. Auch allgemein versucht das Dateisystem eine gewisse Lokalität der Daten zu erreichen. So wird ver- sucht, falls möglich, die Daten einer Datei in Datenblök- ken zu speichern, die physikalisch nahe beim Datei-

4.1.5 Inodes und Inodeliste

Inodes sind in Unix-Dateisystemen die Dateideskriptoren, durch die Dateien definiert sind. Sie beinhalten die Infor- mationen über die Datei, und die Datenblockadressen der zur Datei gehörenden Blöcke. Jede Datei hat einen Inode, aber nicht jeder Inode beschreibt eine Datei¹, schon des- halb, weil üblicherweise auch noch freie (unbelegte) In- odes existieren. Jegliche Operationen auf Dateien werden über diese Index Nodes durchgeführt. Das Dateisystem besitzt eine vorbestimmte Anzahl von Inodes (siehe 4.1.4 Datenblockbitmap und Inodebitmap), üblicherweise 2.048 bei einer Blockgröße von 1.024 Byte. Jeder dieser Inodes ist dateisystemweit durch seine eindeutige Inodenummer identifizierbar. Da jeder dieser Deskriptoren eine definierte Länge von 128 Byte hat, errechnet sich die Länge der auf die Inodebitmap folgende Inodeliste hier auf 256 Blöcke (in diesem Beispiel: 128 Byte * 2.048 Inodes / 1.024 Byte pro Block). Die Länge eines Inodes ist eine feste Größe, da die Adresse eines einzelnen Inodes an keiner Stelle ge- speichert ist und man sie deshalb nur mit einer berechne- ten Distanz vom Beginn der Inodeliste finden kann. Folfeststellen, wo sich die einzelnen Datenblöcke der Datei befinden. Die Tabelle besteht aus 15 Einträgen, die die Adressen der Datenblöcke beinhalten (ersichtlich aus Fig.4.2). Die ersten 12 Einträge verweisen direkt auf die ersten 12 Datenblöcke der Datei (direkte Verweise). Der 13. Eintrag stellt einen Pointer auf einen Block dar, der in seinen 256 Einträgen die Adressen der nächsten 256 Da- tenblöcke enthält (einfacher indirekter Verweis). Der 14. Eintrag der Tabelle zeigt auf einen Block, der Adressen von weiteren 256 Blöcken enthält, die ihrerseits wiederum 256 Blöcke allokieren, die zur Datei gehören (doppelt indirekter Verweis). Der 15. Eintrag der Tabelle der Da- tenblockadressen schließlich enthält einen dreifach indi- rekten Verweis. D.h. er beschreibt einen Pointer auf einen Block mit 256 Blockadressen von Blöcken, die ihrerseits weitere 256 Blöcke adressieren, welche jeweils auf 256 Datenblöcke der Datei verweisen. So wären pro Datei 12+256+256² +256³ = 16.843.020 Blöcke verfügbar, was je nach logischer Blockgröße einer maximalen Dateigröße zwischen 16 und 64 GB entspricht.

Indirect blocks gende sind die Dateiinformationen, die die Inodes darstel- len.

Der Dateimodus beschreibt die Art des Dateisystemob- jektes. Hier sind folgende Werte vorgesehen: normale Datei, Verzeichnis, Verweis, Gerätedatei². Außerdem werden hier die Zugriffsrechte für das Objekt festgehalten. Diese sind bei ext2fs die Standart Unix Zugriffsrechte <Lesen / Schreiben / Ausführen> jeweils für <Besitzer / Gruppe / Welt>. Die Datei hat auch einen Besitzer, das ist der User, der die Datei erstellt hat. Die Nummer des Users (UID) wird als Besitzernummer im Inode vermerkt ge- nauso wie die Gruppenzugehörigkeit des Besitzes. Dies ist notwendig, um die Zugriffsrechte zu realisieren. Ein wei- terer Inhalt des Inodes ist die Länge der Datei in Byte (diese wird in einem 32 Bit-Integer gespeichert), und der sogenannte Timestamp. Dieser beschreibt die History der

Fig 4.2 Datenblockadressen

Abbildung in dieser Leseprobe nicht enthalten

Datei, wie Zeitpunkt des letzten Zugriffs, Erstellung der Datei, letzte Änderung und letzte Löschung. Diese Zeit- punkte werden in Sekunden seit dem 01.01.1970, 0 Uhr gespeichert, wofür jeweils ein 32 Bit-Integer vorgesehen ist. Diese Werte sorgen erst im Februar des Jahres 2106 für einen Überlauf. Und die Genauigkeit einer Sekunde sollte für die Unterscheidung verschiedener Dateien genü- gen. Weitere Dateieigenschaften sind: read only, sicheres Löschen, Schreiben nur ans Ende erlaubt, nicht veränder- bar usw. Auch sie sind im Inode gespeichert. Interessan- terweise wird auch die Anzahl der Verweise auf den Inode protokolliert³.

Die Tabelle der Datenblockadressen stellt wohl den wich- tigsten Teil des Inodes dar. Durch sie läßt sich erst

liebigen Block sind maximal 4 Zugriffe notwendig, da man bereits an der Position des gesuchten Blockes in der Datei erkennen kann, auf welchem Pfad durch den Baum man zum gesuchten Block kommt.

4.1.6 Datenblöcke

Auf Liste der Inodes folgen bis zum Ende der Block- gruppe die Datenblöcke, die die tatsächlichen Daten der Dateien, oder auch Adressenblöcke (siehe letztes Kapitel) enthalten. Ihre Länge ist jeweils die eines logische Blok- kes.

4.2 Logische Struktur

Da nun geklärt ist, wie die physikalischen Strukturen des ext2fs aussehen, wird nur erklärt, wie die logischen Strukturen darauf aufgebaut sind.

4.2.1 Reservierte Inodes

Die ersten 12 Inodes des Dateisystems sind für besondere Aufgaben reserviert. So ist es die Aufgabe des ersten In- odes, eine Liste der “bad blocks” zu führen. Er allokiert dazu alle Datenblöcke bei denen Unzuverläßigkeit festge- stellt wurde und verhindert somit, daß diese Blöcke zur Speicherung von Daten genutzt werden. Dieser erste Inode beschreibt also eine nicht sichtbare Datei, auf die auch nicht zugegriffen werden kann. Der zweite Inode eines Dateisystems beherbergt das Wurzelverzeichnis, was den Vorfahr aller Verzeichnisse und Dateien im Dateisystem darstellt. Der dritte und vierte Inode sind für die Imple- mentierung von Zugriffskontrollisten (Access Control Lists, ACLs) vorgesehen. Mit diesen Listen ist eine differ- enziertere Rechteverwaltung von Dateisystemobjekten möglich, als dies durch die Vergabe von Standart Unix Rechten zu erreichen ist. Da diese ACLs aber bis jetzt zumindest noch nicht in ext2fs implementiert sind¹, er- füllen die Inodes 3 und 4 derzeit keine spezifische Funk- tion, können aber trotzdem nicht für Benutzerdateien ver- wendet werden, da sie ja wie oben schon erwähnt, reser- viert sind. Der Inode 5 ist der Boot Loader Inode. Er refe- renziert das Bootprogramm (für den Fall, daß dieses Da- teisystem das Wurzelverzeichnis beinhaltet, welches den Wurzelknoten im Linuxdateisystem darstellt). Der Inode mit der Nummer 6 ist dem Undelete Directory zugewie- sen. Hierbei handelt es sich um ein nach außen hin nicht sichtbares Verzeichnis, dessen Einträge gelöschte Dateien sind, sofern diese während ihrer Lebzeit mit dem Merkmal “sicheres Löschen” ausgezeichnet waren. Gelöschte Da- teien lassen sich aus diesem Verzeichnis wiederherstellen. Die Inodes 7-12 stellen auch noch reservierte Inodes dar, Datenträger ausfindig gemacht werden. Ein Verzeichnis- eintrag hat folgende Bestandteile: Inodenummer, Länge des Verzeichniseintrags, Namenslänge, Dateiname.

Abbildung in dieser Leseprobe nicht enthalten

Fig 4.3 Ein Verzeichnis

Hier ist der Dateiname ein String einer bestimmten Länge (standartmäßig 255), wobei die Namenslänge angibt, wie- viele Zeichen des Strings den tatsächlichen Dateinamen darstellen. Die Inodenummer ist als 32 Bit Integer reali- siert und kann so 2³² also rund 4 Mrd. Dateien eindeutig identifizieren, was für die meisten Dateisysteme ausrei- chend groß gewählt sein dürfte. Die Länge des Verzeich- niseintrages wird explizit gespeichert, um beim Lesen eines Verzeichnissen bestimmen zu können, ab welcher Position ein neuer Eintrag beginnt. Außerdem wird in jedem Verzeichnis die Inodenummer des aktuellen und des übergeordneten Verzeichnisses protokolliert. Diese Eigen- schaft ist bei einem Filesystem Check von Nutzen. Darge- stellt und qualifiziert werden diese Einträge durch ‘.’ für das aktuelle Verzeichnis, und ‘..’ für das übergeordnete Verzeichnis. Die beiden speziellen Verzeichniseinträge werden beim Erstellen eines Verzeichnisses mitangelegt. Ein Verzeichnis gilt dann als leer, wenn es nur noch die beiden Einträge ‘dot’ und ‘dotdot’ besitzt. Interessanter- weise wird der Name einer Datei, oder eines Verzeichnis- ses nicht im zugehörigen Inode gespeichert, sondern im darüberliegenden Verzeichnis. Da der Zugriff auf ein Dateisystemobjekt immer über den symbolischen Namen incl. Pfadangabe durchgeführt wird, kommt es praktisch nicht vor, daß man einen Inode findet, zu dem man den logischen Ort bzw. den symbolischen Namen finden will¹. Liest man ein Verzeichnis, so können linear alle Namen (und nur für die interessiert sich der Benutzer) aus den Verzeichniseinträgen vom Datenträger gelesen werden. Wäre der Name nur im Inode des Objektes gespeichert, so müßte man beim Lesen eines Verzeichnissen alle dort

i_love_you.vbs 63A5A3F1

isapnp.conf 63A53BB2

usr 33F2272F

hello_world.java D22FF231

some_mp3s 556B1157

Mehrbenutzersystem legt ein User B einen Hardlink auf einen Inode an, welcher eine Datei des Users A referen- ziert (falls er das Recht dazu hat). Löscht nun User A “seine” Datei, so verliert er die Möglichkeit, weiterhin darauf zuzugreifen. Denn die Datei wird nicht tatsächlich gelöscht, da User B den Inode noch referenziert. Sind in diesem System Diskquotas eingerichtet, wird durch diese Datei weiterhin das Konto von A belastet, obwohl er nicht erkennen kann, wodurch die Belastung zustande kommt. Würde diese Datei tatsächlich gelöscht, wenn der Besitzer A seinen Link löscht, so hätte Mitbenutzer B einen ungül- tigen Verzeichniseintrag in einem seiner Verzeichnisse. Problematisch wird es aber dann, wenn das Dateisystem diesen Inode wieder für eine andere Datei oder ein anderes Verzeichnis benutzt. Mitbenutzer hätten dann unbeabsich- tigt Zugriff auf Daten, die vielleicht vor ihnen geheim gehalten werden sollten. Allgemeiner: Dieses Instant De- leting würde zu einer Lücke in der Systemsicherheit füh- ren.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 4.5 Hard Links

Im übrigen ist bei Verzeichnissen nur ein Referenzwert von 1 erlaubt. Dies vermeidet zuverlässig das Auftreten eines Zyklus im Dateibaum. Im Normalfall ist der Wert des Zählers auch bei normalen Dateien =1, da schon ein einfacher Verzeichniseintrag einen Hardlink darstellt. Erst wenn er den Wert 0 erreicht und der Inode somit voll- ständig dereferenziert ist, ist die Datei tatsächlich gelöscht. Wenn das Attribut “sicheres Löschen” gesetzt ist, wird der Verzeichniseintrag in den Undelete Directory Inode¹ kopiert. Der Wert 0 des Referenzcounters bedeutet, daß der Inode unbelegt ist, und für eine neue Aufgabe zur Verfügung steht). Ein und dieselbe Datei kann also in mehreren Verzeichnissen doppelt existieren, obwohl sie physikalisch nur einmal vorhanden ist. Dabei ist keine Namesgleichheit vorgeschrieben. Hardlinks sind beauftauchen. Aber das ist ein Problem des Prozeßmanage- ments. Ein Eintrag in dieser Tabelle existiert nur solange, wie sich eine Datei im Zugriff befindet. Das läßt sich anhand des Referenzcounters einfach feststellen.

Zusätzlich zu der sytemweiten Dateitabelle führt jeder Prozeß für sich eine prozeß-spezifische Dateitabelle. Darin listet der Prozeß alle von ihm geöffneten Dateien auf. Die Einträge sind direkte Verweise auf die Einträge in der systemweiten Dateitabelle. Die Tabelle ist als Array einer festen Länge implementiert, um einen schnellen Zugriff zu gewährleisten. Standartmäßig faßt diese Tabelle 256 Ein- träge, was aber mit relativ geringem Aufwand verändert werden kann. Da die ersten 3 Einträge für bestimmte Auf- gaben reserviert sind, kann jeder Prozeß noch 253 weitere Dateien parallel im Zugriff halten. Die reservierten Ein- träge mit den Indizes 0-2 stellen den Standarteingabe-, Standartausgabe- und den Standartfehlerkanal dar (stdin, stdout, stderror). Fig. 4.6 zeigt symbolisch auf welchem Weg ein Prozeß auf eine Datei zugreift. Verlangt ein Pro- zeß Zugriff auf eine Datei, so tut er dies, indem er dem Kernel den Pfad- und Dateinamen übergibt. Findet dieser einen zugehörigen Inode, so wird dieser auf dem Daten- träger ausfindig gemacht. Im nächsten Schritt werden die Zugriffsrechte des Prozesses auf die Datei überprüft, und falls der Prozeß das angeforderte Recht auf die Datei tat- sächlich besitzt, so wird der Inode in den Arbeitsspeicher kopiert.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 4.6 Ein Dateisystemzugriff

Nun wird für den Inode ein Eintrag in der Systemweiten Inodetabelle generiert; oder besser gesagt: Der Inode selbst wird hierher kopiert, mit den oben schon erwähnten Zusatzinformationen. Danach wird der systemweiten Da- teitabelle ein neuer Eintrag hinzugefügt, wovon die wich- tigste Information ein Zeiger auf den vorher erzeugten Eintrag in der Inodetabelle ist. Der Positionszeiger wird ebenfalls jetzt erzeugt. Abschließend wird dem Prozeß noch mitgeteilt, wo er die angeforderte Datei finden kann. Dazu wird in seiner prozeß-spezifischen Dateitabelle ein Zeiger auf den entsprechenden Eintrag in der systemwei- ten Dateitabelle erzeugt. Befindet sich die Datei bereits im Zugriff eines anderen Prozesses, so wird nur ein Zeiger von der prozeß-spezifischen Dateitabelle auf den entspre- chenden Eintrag der systemweiten Dateitabelle erzeugt und der Referenzcounter in letzterem inkrementiert. Ob die Datei schon benutzt wird oder nicht, ist einfach fest- zustellen, da direkt nach der Namensauflösung der An- frage nach einem entsprechendem Eintrag in der system- weiten Dateitabelle gesucht wird. Nur wenn diese Suche erfolglos ist, wird oben beschriebenes Verfahren eingelei- tet, um dem Prozeß den Zugriff zu ermöglichen.

4.2.4 File System Check

Um die Redundanz in ext2fs zu ermöglichen, müssen einige Informationen an verschiedenen Stellen abgelegt werden. Legt man eine Datei an, so müssen einige Schritte vollzogen werden¹: Anlegen eines Verzeichniseintrages, Initialisierung des Inodes, Schreiben und Allokieren der Datenblöcke, Änderungen in den entsprechenden Bitmaps für Datenblöcke und Inodes. Da z.B. ein Stromausfall während einer solchen Transaktion zu Inkonsistenzen im Verwaltungslayer des Dateisystems führen kann, hält Linux einige mächtige Tools bereit, um ext2fs im Falle eines Defektes wieder in einen konsistenten Zustand über- führen zu können. E2fsck , welches auf einem von Linus Torvalds entwickelten File System Checker für Minix basiert, dürfte wohl eines der interessantesten sein. Seine Funktionsweise soll im folgenden erklärt werden⁶. E2fsck prüft das Dateisystem nach dem Aufruf (z.B. e2fsck /dev/sde3) in 5 Schritten:

Im ersten Schritt (inodes structure check) werden alle In- odes vom Datenträger gelesen und unabhängig von ihren Verknüpfungen untereinander auf Korrektheit geprüft; z.B. wird geprüft, ob alle Blocknummern in den Daten- blockadressentabellen der Inodes gültige Blocknummern darstellen. Aus den gewonnenen Informationen über die Inodes werden dann die Bitmaps neu erstellt. Einen freien Inode erkennt man daran, daß sein Referenzcounter den Wert 0 enthält, einen freien Datenblock erkennt man daran, daß er von keinem der Inodes adressiert wird. Au- ßerdem wird die im Inode gespeicherte Dateilänge mit der Anzahl der allokierten Blöcke verglichen. Wird in diesem ersten Durchlauf festgestellt, daß ein Block durch mehrere Inodes referenziert wird, so werden weitere Schritte 1A bis 1D durchlaufen. Handelt es sich um offensichtlich gleiche Dateien, so sorgen diese Arbeitsgänge dafür, daß die zu- viel vorhandenen Inodes gelöscht werden. Sind es nur einzelne Blöcke, die mehreren Inodes zugeordnet sind, wird für jeden Inode eine eigene Kopie der Blöcke ange- legt. Die Aufgabe des zweiten Schrittes (directory struc- ture check) ist es, herauszufinden, ob alle Verzeichnisse konsistent sind. Dabei werden alle Verzeichniseinträge auf ihre Gültigkeit geprüft. Danach sollte kein Verzeichnis- eintrag mehr einen freien Inode referenzieren. Wird ein Verzeichnis von mehr als einem anderen Verzeichnis referenziert, so werden alle zuviel vorhandenen Verweise gelöscht, da sie als nicht erlaubte Hardlinks gelten und nicht in Einklang gebracht werden können mit dem Vor- haben einen Datei”baum” zu implementieren. Diese ille- galen Hardlinks sind am Wert des Referenzcounters zu erkennen. In jedem Verzeichnis ist außerdem auch noch die Inodenummer des aktuellen und des übergeordneten Verzeichnisses vorhanden¹ (current directory und parent directory). Die Existenz der beiden Einträge wird nun überprüft, ihre Korrektheit aber erst im nächsten Schritt. Im dritten Arbeitsgang (directory connectivity check) werden die Verweise der Verzeichnisse untereinander gecheckt. Dabei wird für jedes Verzeichnis eine Trace- Route angelegt. Diese sollte immer im Wurzelverzeichnis enden. Finden sich Verzeichnisse, die diese Eigenschaft nicht erfüllen, werden sie im Verzeichnis /lost+found abgelegt. Auch belegte Inodes, die keinem Verzeichnis zugeordnet werden konnten, werden dort im vierten Schritt (reference counter check) verzeichnet. Abschließend wer- den im fünften Schritt (group summary check) die gesamt- heitlichen Informationen über das gesamte Dateisystem geprüft. Dazu werden die im ersten Schritt neu erstellten und in den folgenden Schritten eventuell nachgebesserten Bitmaps mit den auf dem Datenträger vorliegenden vergli- chen, und bei Bedarf korrigiert.

E2fsck ist besonders effizient, da es alle vom Datenträger gewonnenen Informationen cached und in nachfolgenden Schritten weiterverwendet und aktualisiert. Nach Arbeits- schritt 2 müssen keine Daten mehr vom Datenträger gele- sen werden. Deshalb benötigen die Schritte 3,4 und 5 nur noch 5-10% der gesamten Laufzeit von E2fsck⁶.

Auf keinen Fall sollte dieses Programm auf einem ge- mounteten Dateisystem ausgeführt werden. Falls dies nicht möglich ist, sollte das Dateisystem zumindest schreibge- schützt (read-only) gemountet sein. Der Grund liegt auf der Hand. Haben andere Prozesse während des Prüflaufes schreibenden Zugriff auf den Datenträger, kann es zu Unstimmigkeiten mit den bei den einzelnen Prüfschritten vollzogenen Checks kommen. Erkennt E2fsck diese Fehler so versucht es, Fehler zu beheben, die gar nicht existieren. Bei einem solchen Check wird unter Umständen mehr zerstört, als gewonnen wird⁵.

5. VIRTUELLES DATEISYSTEM (VFS)

Schon früh erkannten die Linux - Entwickler, daß es nicht ihrer Motivation entsprach, ein einziges Dateisystem fest in den Kernel zu implementieren. Sie entschieden sich für ein Konzept, welches auch in Unix angewendet wird - das Virtuelle Dateisystem (Virtual Filesystem, VFS). Die Idee besteht darin, einen zusätzlichen Layer zu benutzen, und die Operationen, die auf dem Dateisystem auszuführen sind, so zu halten, daß sie nicht von der jeweiligen techni- schen Ausführung eines Dateisystems abhängig sind. Wie werden müssen. Für FAT Dateisysteme ist der Umgang mit Inodes vollkommen fremd, da diese mit Dateizuord- nungstabellen (File Allocation Table) arbeiten. Der FAT

- Treiber muß eine Emulation vieler Strukturen und Opera- tionen bieten. Das ändert aber nichts an der Tatsache, daß unter Linux trotzdem seine volle Funktionalität genutzt werden kann.

6. LEISTUNGSBEWERTUNG UND GRENZEN VON EXT2FS

6.1 Datenrettung für Abenteurer

Hat man eine Datei gelöscht, so besteht auch weiterhin noch die Möglichkeit, sie wiederherzustellen. Beim Lö- schen einer Datei wird der Linkcounter auf 0 gesetzt, der Inode wird in der Inodebitmap seiner Blockgruppe als frei gekennzeichnet und die vom Inode referenzierten Blöcke werden in ihren entsprechenden Blockbitmaps als wieder verfügbar eingetragen. Danach enthält der Inode aber immer noch sämtliche Informationen über das ehemalige Objekt. Auch die Daten in den Datenblöcken bleiben weiterhin bestehen, sofern diese nicht explizit über- schrieben werden. Ist seit dem Löschen der Datei noch nicht allzuviel Zeit vergangen (d.h. es gab seit dem noch nicht so viele Schreibzugriffe auf den Datenträger), so hat man gute Chancen, die Datei wieder vollständig herzustellen. Zu diesem Zweck leistet das Programm debugfs gute Dienste. Mit ihm läßt sich das Dateisystem auf relativ tiefer Ebene erforschen und es bietet die Möglichkeit, gezielt Änderungen vorzunehmen; unter anderem bietet dieses Programm auch die Möglichkeit, gelöschte Dateien wiederherzustellen. Um tatsächlich Änderungen vorzunehmen, muß man das Dateisystem explizit als beschreibbar öffnen. Dies soll eine wirksame Sicherheitsschranke darstellen, da man mit diesem Pro- gramm sehr schnell sehr viel zerstören kann. Allerdings sollte man debugfs nur auf nicht gemounteten Dateisyste- men benutzen, aus den selben Gründen, die auch schon im Kapitel 4.2.4 “FileSystem Check” für die Benutzung von e2fsck beschrieben wurden. Wie man im Listing 1 sehen kann, bietet debugfs dazu manigfaltige Möglichkeiten. Mit dem Befehl lsdel lassen sich Daten zu allen gelöschten Dateien des aktuellen Dateisystems anzeigen. Diese wer- den aus dem Undelete Directory gewonnen¹. Die Daten- sätze bestehen aus der Inodenummer, der User ID des Dateibesitzers, dem Dateimodus, der Dateigröße in Byte, die Anzahl der dafür verwendeten Blöcke (auch die An- zahl der Blöcke, die noch nicht für andere Dateien verge- ben wurden) und den Zeitpunkt, zu dem diese Datei ge- löscht wurde. Leider sind die Namen der Dateien nicht wieder herzustellen. Hat man also eine Inodenummer gefunden, die einem plausibel erscheint, kann man sich mit “stat <Inodenummer>” nähere Informationen zu die- sem Inode besorgen². In Listing 3 findet sich ein Beispiel hierzu. Mit dump “<Inodenummer> Dateiname” lassen sich schließlich die zum Inode gehörenden Blöcke wieder in eine Datei schreiben. Dabei sollte unbedingt auf ein anderes Dateisystem geschrieben werden, als das, auf welchem debugfs gerade arbeitet. Es könnte nämlich sein, daß gerade die Blöcke, die man zu retten beabsichtigt dabei unwiederbringlich überschrieben werden.

6.2 Große Dateien

Wie oben³ beschrieben, lassen sich durch einen Inode 16.843.020 Datenblöcke allokieren. So würde man zum Schluß kommen, daß man mit einer Blockgröße von 4.096 Byte Dateien mit bis zu 64 GByte anlegen könnte. Leider verhindert dies eine Schranke, die schon wesentlich tiefer angelegt ist. So wird der Offset in einer Datei in Byte ab dem Dateianfang in einem vorzeichenbehafteten 32 Bit Integer festgehalten. Das ergibt eine maximale Dateigröße von 2³¹ -1Byte, was knapp 2 GByte entspricht. Nun stellt man sich die Frage, warum hier negative Offsets vorgese- hen sind. Diese negativen Werte dienen einigen Dateiope- rationen als Fehler-Rückgabewerte. Ab der Kernelversion 2.2 werden an dieser Stelle aber vorzeichenlose 32 Bit Werte verwendet, was eine maximale Größe von knapp 4 GByte ermöglicht. In Systemen mit 64 Bit Prozessoren sind schon längere Zeit größere Dateien möglich. Das liegt daran, daß die 32-Bit breiten x86 - Prozessoren nur ineffi- zient mit den langen 64 Bit Werten arbeiten, was sich bis vor kurzem auf noch nicht so schnellen Maschinen stark bemerkbar gemacht hat. In neueren Entwicklerkernels wird der File Offset als 4 KByte Seite gehandhabt, mit denen man Größen bis zu 16 TByte (2³² x 4096) adressie- ren kann. Das wäre eine Größe die, die bis jetzt maximale Partitionsgröße von 2 TByte übersteigt. Größere Partitio- nen sind auch in Zukunft noch nicht in Aussicht, da einige Komponenten im i368 Kernel noch mit maximal 2³² 512 KByte-Blöcken hantieren können. Eine Weiterentwick- lung ist erst ab Kernelversion 2.5 vorgesehen. Nur 2 Punkte kommen in ext2fs mit der Dateigröße in Berüh- rung: Im Inode wird die Größe einer Datei als 32 Bit Inte- ger gespeichert. Diese Schranke läßt sich heben, indem man weitere 32 Bit hinzunimmt, um die Dateilänge in 64 Bit zu beschreiben. Betrachtet man die Struktur eines Inodes, so bemerkt man, daß der für ACLs (access control lists) reservierte Speicherplatz brach liegt. Und wie oben schon erwähnt, ist nicht einmal sicher, ob diese jemals in ext2 implementiert werden. Also kann man diese 32 Bit nutzen, um die Dateilänge zu 64 Bit aufzustocken. Der zweite Berührungspunkt zur Dateigröße ist die Anzahl der

“stat” nimmt als Parameter auch den Dateinamen einer nicht gelöschten Datei entgegen.

allokierbaren Blöcke pro Inode. Werden nur 11 Direkt- adressen anstatt der üblichen 12 im Inode verzeichnet, und stattdessen ein Eintrag zu einer weiteren dreifach indirek- ten oder sogar vierfach indirekten Adressierung verwen- det, so kommt man hier auf eine maximale Dateilänge von 128 GB oder sogar 16 TB (bei einer Blockgröße von 4.096 Byte. Wie man sieht, gibt es also genügend Ansatzpunkte um das Dateisystem ext2 den Anforderungen aktueller Aufgabenstellungen anzupassen.

6.3 Sparse Files

Es gibt in Unixsystemen, zu denen ja auch Linux zählt, eine Möglichkeit, Dateien, die lange Ketten von Nullen enthalten, wesentlich effizienter zu speichern, als andere Dateien. Genauer gesagt: Wird ein ganzer Datenblock einer Datei nur mit Nullen belegt, so wird dieser Block nicht tatsächlich auf den Datenträger geschrieben. Dateien, bei denen auf diese Methode ein oder mehrere Blöcke ausgelassen werden, nennt man Sparse Files (“schlanke Dateien”). Die fehlenden Blöcke werden dann als holes (Löcher) bezeichnet.

Man sollte zur Kenntnis nehmen, daß diese Dateien keine komprimierten Dateien im eigentlichen Sinne darstellen, denn Sparse Files sind schon beim Lesen exakt die Da- teien, die sie wären, wenn sie diese Technik nicht einset- zen würden. Der Kernel generiert für fehlende Blöcke einfach eine Kette von Nullen mit der entsprechenden Länge (ein Block). Das bedeutet, daß im Extremfall die Summe der Dateilängen in einem Dateisystem größer sein kann als das Dateisystem selbst.

Sparse Files entstehen zum Beispiel, wenn man einen Zugriff über das Ende einer Datei hinaus tätigt und dann schreibt. Weiß man über die Entstehungsgeschichte der Spares Files Bescheid, läßt sich erkennen, daß wohl be- sonders Anwendungen wie Random Access Databases (Datenbank Applikationen, die wahlweisen Zugriff auf die Daten erlauben) diese Dateien erzeugen. Die Nutzung von Sparse Files ist nicht standartmäßig in ext2 vorgesehen, es ist aber durchaus möglich diese Technik mit ext2fs zu nutzen.

7. AUSBLICK

Was bringt die Zukunft?

Kommt es während des laufenden Betriebs zu einem Stromausfall werden dabei die gemounteten Dateisysteme nicht sauber ausgehängt, mal abgesehen vom Vorhanden- sein einer USV (unabhängige Stromversorgung). Wie in Kapitel 4.2.4 (Filesystemcheck) schon beschrieben, kommt dann meist das Tool e2fsck zum Einsatz, was das Dateisystem auf interne Konsistenz prüft, und gegebenen- falls auch Reperaturen vornimmt. Handelt es sich dabei um ein großes Dateisystem mit vielen Dateien, komplexen Verzeichnisstrukturen und Links, so kann die Laufzeit dieses Programmes durchaus einige Stunden in Anspruch nehmen. Da Dateisysteme, die gerade gecheckt werden, auf keinen Fall gleichzeitig benutzt werden sollten (aus Gründen, die auch schon in Kapitel 4.2.4¹ angesprochen wurden), führt dies zu einer längeren Ausfallzeit. Und das ist vor allem beim Serverbetrieb ungünstig.

Besser wäre es, nur die Dateien zu prüfen, die sich zum Zeitpunkt des Stromausfalls im Zugriff befanden. Dazu führen aber herkömmliche Dateisysteme keine Informa- tionen mit sich. Hier kommen die Journaling Filesysteme zum Einsatz, die eine Liste führen über die jeweils geöf- fneten Dateien, ein sogenanntes Journal. Beispiele hierfür sind ext3fs - der Nachfolger des ext2fs - und ReiserFS, ein von Hans Reiser im Rahmen einer Privatstudie entwickel- tes Dateisystem mit Journal. Nach einem Stromausfall müssen nur die Dateien, die geöffnet waren auf ihre Kon- sistenz geprüft werden. Da sich diese schnell herausfinden lassen, bedeutet hier ein Dateisystemcheck nach einem Stromausfall eine Ausfallzeit von meistens nicht mehr als ein paar Sekunden. Um ein Journal zu implementieren bringt man den Begriff der Transaktion ins Spiel. D.h. alle Daten behalten so lange ihre Gültigkeit, bis alle Operatio- nen, die diese betreffen vollständig abgeschlossen sind. Damit bekommt man sogar Fehler in den Griff , die durch unvorhergesehen abgebrochene Schreibvorgänge verur- sacht wurden⁹.

Beim Third Extended Filesystem (ext3fs) handelt es sich eigentlich nur um eine Weiterentwicklung des ext2fs mit der Möglichkeit des Einsatzes eines Journals. ReiserFS dagegen kann noch mit einer Reihe weiterer technischer Raffinessen aufwarten. Verzeichniseinträge werden in B- Bäumen gespeichert. Was einen viel schnelleren Zugriff erlaubt, wenn man nach bestimmten Einträgen sucht. Au- ßerdem gibt es in diesem Filesystem keinen Clusterver- schnitt mehr, da Dateireste, einzelne Verzeichniseinträge oder Links in einem Block zusammengefaßt werden kön- nen. Obwohl der Code offensichtlich komplexer und damit auch fehleranfälliger sein muß, hat sich ReiserFS zu einem alltagstauglichen Dateisystem entwickelt und ist offiziell in der SUSE Distribution ab Version 6.4 mit dabei.

8. ZUSAMMENFASSUNG

Das Second Extended Filesystem ist wohl nicht ohne Grund zum Standart Linuxdateisystem avanciert. Argu- mente, die den ziemlich flächendeckenden Einsatz dieses Systems rechtfertigen, sind in den vorangegangenen Ka- piteln ausführlich beschrieben worden. Als höchstpriori- siert kann wohl die Tatsache angesehen werden, daß ext2fs eine hervorragende Stabilität aufweist. Auch das Konzept der Wiederherstellung von Verwaltungsinforma- tionen ist gut durchdacht. Da durch die Art der Datenträ- gerverwaltung eine gewisse Redundanz wichtiger Verwaltungsdaten gegeben ist, ist die Chance einer vollständi- gen Wiederherstellung der Daten nach einem nicht allzu schweren Defekt ziemlich hoch; schon allein deshalb, weil diese wichtigen Daten physikalisch über das ganze Da- teisystem verteilt sind. Das hat aber auch noch einen wei- teren Vorteil. Da sich die Inodes nicht in einem, bestimm- ten Bereich auf dem Datenträger befinden, sondern jede Blockgruppe eine bestimmte Anzahl besitzt, läßt sich eine gewisse Lokalität der Daten erreichen. Neue Verzeichnisse werden immer in der Blockgruppe angelegt, die zum aktu- ellen Zeitpunkt die wenigsten Verzeichnisse besitzt; an- genommen es stehen hier noch freie Inodes zur Verfü- gung. Nach Möglichkeit werden für Dateien aufeinander- folgende Datenblöcke benutzt. Das alles führt dazu, daß die Kopfbewegungen des Datenträgers minimiert werden, somit werden entscheidende Geschwindigkeitsvorteile erreicht. Hierzu finden sich einige aufschlußreiche Tabel- len in einem Paper des MIT⁶. Beim Bonnie benchmark wird die I/O-Geschwindigkeit anhand einer großen Datei (in diesem Beispiel 60 MByte) gemessen. Dabei zeigte sich, daß ext2fs überragend hohe Geschwindigkeiteswerte in der Sparte “block-oriented I/O” liefert, was auf die ausgereiften Allokierungsmethoden zurückzuführen sei. Ein anderer Benchmark, der an dieser Stelle durchgeführt wird, ist der Andrew benchmark. Dieser läuft in 5 Phasen ab, wobei eine Verzeichnishirarchie erzeugt wird und Dateien erstellt und kopiert werden. Auch hier zeigt sich, daß ext2fs mit den Leistungswerten der ebenfalls geteste- ten Dateisysteme BSD und XIAfs durchaus mithalten kann. Die genauen Abläufe der Benchmarks und der Kon- figuration, unter der sie durchgeführt wurden, sind in⁶ ausführlich beschrieben.

Schon von der Planungsphase an war klar, daß ext2fs die Möglichkeit bieten sollte, auch in späteren Entwicklungs- phasen noch neue Funktionalität zu implementieren. Bei- spiele hierfür sind die noch unbenutzen Integers des In- odes, die eigentlich zum Implementierung von ACLs (Access Controll Lists) gedacht sind¹, oder die für spezi- elle Zwecke reservierten 12 ersten Inodes jedes Dateisy- stems, von denen bis jetzt auch nur 4 tatsächlich genutzt werden².

Auch die Tatsache, daß das Second Extended Filesystem schon lange nicht mehr nur ein Linux Dateisystem ist, zeigt das Vertrauen der Entwickler in dieses System. In⁶ findet sich eine ganze Reihe von Systemen, auf die ext2 schon portiert wurde, und auch erfolgreich eingesetzt wird. Auch wenn der Nachfolger ext3fs und ReiserFS stark im kommen sind, so läßt sich mit ziemlicher Sicherheit sagen, daß ext2 auch in nächster Zeit noch das Standartdateisy- stem für Linux sein wird.

11. ANHANG

Abbildung in dieser Leseprobe nicht enthalten

[...]

---

¹ Diese Aufzählung ist an die Tabelle in [2] S.253f. angelehnt.

² Siehe Kapitel 4 Ext2fs

³ siehe Kapitel 7 Ausblick

¹ Dieses Konzept verdient eine genauere Betrachtung, weshalb ihm noch ein ganzes Kapitel gewidmet ist (Kapitel 5 Virtuelles Dateisystem).

¹ Siehe Kapitel 4.2.4 Filesystemcheck

¹ siehe Kapitel 4.2.1 Reservierte Inodes

² siehe Kapitel 4.2.2 Dateitypen

³ siehe Kapitel 4.2.2.2 Links

¹ siehe Kapitel 4.2.1 Reservierte Inodes

² siehe Kapitel 4.2.2 Dateitypen

³ siehe Kapitel 4.2.2.2 Links

¹ Ob diese ACLs überhaupt noch in ext2 integriert werden ist fraglich, da es auch schon neuere Versionen von extfs gibt, z.B. ext3fs

² siehe Kapitel 4.2.2.2 Links

¹ Wäre aber natürlich möglich; man müßte alle Verzeichnisse lesen und nach korrespondierenden Einträgen in der Inodeliste suchen. Durchschnittlicher Rechenaufwand bein Dateien liegt bei n/2 Zugriffen.

² Siehe Kapitel 4.1.5 Inodes und Inodeliste

¹ Siehe Kapitel 4.2.1: Reservierte Inodes

² Genauer gesagt: in einer systemweiten Inodetabelle

¹ Ohne Beachtung der Reihenfolge

¹ siehe Kapitel 4.2.1 Reservierte Inodes

² “stat” nimmt als Parameter auch den Dateinamen einer nicht gelöschten Datei entgegen.

³ siehe Kapitel 4.1.5 Inodes und Inodeliste

¹ Kapitel 4.2.4 FileSystem Check

¹ siehe Kapitel 4.1.5 Inodes und Indeliste

² siehe Kapitel 4.2.1 reservierte Inodes

• College: University of Ulm
• Course: Proseminar Linux
• Grade: ohne
• Author: Marco Berroth (Author)
• Publication Year: 2000
• Pages: 18
• Catalog Number: V97505
• ISBN (eBook): 9783638959575
• Language: German
• Tags: Logische, Struktur, Second, Extended, Filesystem, Linux, Proseminar, Linux