Ja, eine interessante Fragestellung ist jetzt natürlich in dem Zusammenhang auch, wie Kataloge,

also Direktories implementiert werden. Bei kurzen Katalogen ist es wieder genauso wie mit den

Dateien. Da wird die komplette Information, diese File Referenz, einfach mit im Stream in der

Master File Table gespeichert. Das ist also dann ein Index Stream und der besteht im Endeffekt

immer aus drei Einträgen. Das erste ist die File Referenz, also die Ein- und Nummer quasi oder die

Referenz auf ein Master File Table Eintrag. Dann steht an der Stelle der Dateiname, ist natürlich

ja im Prinzip auch wie bei Unix Directories so, und es steht aber noch die Dateilänge dabei.

Die Dateilänge wird natürlich auch in der Datei selber gespeichert, in dem Verwaltungstream dort,

aber man hält sie noch mal im Index mit, weil das eine Information ist, die man bei der Anzeige von

Directories üblicherweise unmittelbar braucht. Also ein normaler File Browser zeigt das halt mit an.

Und um den zusätzlichen Zugriff sich zu sparen, hat man sich da entschieden, dass man diese

Information lieber redundant speichert. Hat natürlich zur Folge, wenn sich die Länge einer

Datei ändert, dann muss ich es nicht nur im Stream der Datei, sondern eben auch im entsprechenden

Katalog Stream aktualisieren. Das ist gewisser mehr Aufwand, aber dafür tut man sich natürlich beim

Anschauen der Kataloge leichter. Nachdem üblicherweise Kataloge wohl öfters gelesen werden,

als das Datein verändert werden, ist das einfach eine Abwägungsfrage, wo gewinne ich mehr Effizienz an.

Ja gut, und dann gibt es noch eine Belegungstabelle, wo letztlich drinsteht, wie dieser Index belegt ist.

Wenn so eine Datei größer wird, dann passt natürlich dieser Index auch nicht mehr rein,

und dann arbeitet das Ganze auch wieder mit einem Erweiterungskonzept. Das heißt, ich adressiere

hier wieder Extents und habe da auch wieder meine Virtual-Cluster-Nummer, meine Logical-Cluster-Nummer

und die Länge des Extents. Und in so einen Extents passt dann eben wieder eine weitere Zahl von Dateien

rein. Also jetzt in diesem Bild habe ich jetzt pro Cluster nur eine Datei reingespeichert. Also hier

in den Blöcken 89, 90, 91 und 92 sind also jetzt diese vier Logical-Cluster. Da stehen jetzt drei

Dateien drin und in den Blöcken 173, 174, 175, 176, da stehen auch drei Dateien drin. Da ist also

zwischendrin mal ein Eintrag frei, es hat eine Datei gelöscht worden. Und die Dateien werden

da drin sortiert gespeichert. Es ist also ein B-Plus-Baum. Das sind Konzepte aus dem Datenbank-Bereich,

wie man sehr effizient eben solche Datenmengen abspeichern kann. Und da will ich jetzt im Detail

nicht auf die B-Baum-Algorithmen eingehen, aber es ist also eben eine Methode, um eben auch sehr

große Verzeichnisse eben sehr schnell durchsuchbar zu machen. Man muss ja also nicht linear durchsuchen,

sondern man kann in diesem Baum dann durch Baumtraversieren eben sehr schnell zum Ziel kommen. Und

in so einen Cluster passen eben nicht nur wie in dem Beispiel hier jeweils eine Datei rein, sondern

irgendwo zwischen drei und 15 Dateien, je nachdem wie groß ein Eintrag für so eine Datei ist und

auch wie groß die Cluster sind. Schauen wir uns nochmal die Master File Table an. Die wird ja nicht

nur verwendet, um Dateien zu speichern, sondern da drin liegt auch eine ganze Reihe von Metadaten,

die eben zur Verwaltung dieses Dateisystems benötigt werden. Im ersten Eintrag dieser Master

File Table steht die Master File Table selbst. Die Master File Table selbst ist quasi auch eine

Datei und eine Datei besteht ja aus einer Reihe von Chunks, Blöcken. Und im Endeffekt in diesem

ersten Eintrag steht, wo die Master File Table steht. Also im Endeffekt diese ganzen Folgeblöcke,

also diese Chunks, sind eben hier drin eingetragen. Und das interessante ist halt, wenn die Master

File Table jetzt von der Größe her nicht reicht, dann kann ich sie auf die Weise natürlich ganz

leicht ergänzen, indem ich hier oben einfach einen weiteren Chunk eintrage und der verweist dann

eben wieder auf eine Menge von Datenblöcken irgendwo auf der Platte, die eben dann auch zur

Master File Table gehören. Also auf die Weise wird die Master File Table selbst genauso flexibel in

der Verwaltung wie jede normale Datei auch. Also sie verwaltet sich quasi selbst. Nachdem die

Master File Table natürlich wichtig ist, weil da drin natürlich letztendlich alle Informationen

steht, wo was steht, wird sie nochmal kopiert, um im Ernstfall, wenn was kaputt geht, irgendwie

sie eben nochmal zu haben. Dann kommt das Log File. Auf das gehe ich dann nochmal detaillierter ein,

wenn ich auf dieses Konzept der Log Structure File Systeme eingehe. Dann die Volume Information,

die enthält solche Sachen wie Name, Größe und ähnliche Attribute des Volumes. Als nächstes

kommt dann die Attributtabelle, die beschreibt die möglichen Streams, die es in diesem Dateisystem