726574

Zeiger im Byte-Chaos

Alles, was am Computer geschieht, setzt eine irgendwo gespeicherte Datei voraus. Anhand des meistverbreiteten Dateisystems FAT zeigen wir, wie Betriebssysteme die Dateien verwalten.

Anforderung

Profi

Zeitaufwand

Hoch

Windows, Linux oder Mac-OS: Alles, was am Computer geschieht, setzt eine irgendwo gespeicherte Datei voraus. Anhand des meistverbreiteten Dateisystems FAT zeigen wir, wie Betriebssysteme die Dateien verwalten.

Den meisten Platz auf Ihrer Festplatte belegen Benutzer- und Programmdateien. Diese Daten können Sie sich im (Windows-) Explorer, unter DOS oder über Anwendungsdialoge anzeigen lassen. Auf gewünschte Dateien greifen Sie über die Ordner- und Dateinamen zu. Außer über den Namen bestehen weitere Zugriffsmöglichkeiten über Dateiattribute, Zeitdaten oder Dateigröße.

Doch was geschieht unter der Motorhaube des Betriebssystems, wenn Sie ein Verzeichnis öffnen oder eine Datei laden? FAT & ROOT Von Clustern und Namen Die Tatsache, daß sich Dateien über Name, Extension oder Datum filtern und laden lassen, ist für uns ein selbstverständlicher System-Service. Er erfordert intern einiges an Verwaltungsaufwand, denn das Betriebssystem hat mit Namen an sich nichts am Hut: Es verwaltet die Dateien nämlich anhand durchnumerierter Zuordnungseinheiten, sogenannter Cluster. Nehmen wir an, Sie rufen die Datei Rechnung34.DOC auf. Woher weiß nun das System, daß es die Daten aus Cluster 12057 und 12058 zu laden hat?

Und woher weiß es, welche Dateinamen es anzeigen muß, wenn Sie im (Windows-)Explorer auf "Eigene Dateien" klicken? Im - organisatorisch gesehen - vorderen Teil der Festplatte, unmittelbar nach dem reservierten Startbereich mit der Partitionstabelle und dem Bootsektor, existieren zwei entscheidende Tabellen: Die umfangreichere der beiden ist die FAT (File Allocation Table), die nur aus hexadezimalen Werten besteht. Die FAT enthält für jeden auf der Platte verfügbaren Cluster - etwas vereinfacht dargestellt - entweder einen der drei folgenden reservierten Werte: 00 00 freier Cluster FF F7 fehlerhafter Cluster FF FF Schluß-Cluster einer Datei (<EOF>) Oder sie enthält einen beliebigen anderen Wert: <xx xx> nächster Cluster einer Datei <xx xx> ist dann die Nummer jenes Clusters, der die nächstfolgenden Daten einer Datei enthält. Somit ist klar: Hat das System erst einmal den Start-Cluster einer Datei gefunden, kann es anhand der Cluster-Zeiger in der FAT-Tabelle auch die Folge-Cluster ermitteln - bis hin zum Schluß-Cluster.

Das Bindeglied zwischen der spröden Cluster-Nummer und den anwenderfreundlicheren Eigenschaften von Dateinamen & Co. bilden die sogenannten Verzeichniseinträge. Damit sind wir bei der zweiten Ta-belle angelangt - der Root-Verzeichnistabelle, die unmittelbar nach der FAT folgt: Jede Datei und jeder Ordner sind hier mit einem 32 Bytes langen Eintrag repräsentiert (ein Ordner ist nichts anderes als eine Datei mit dem Attribut "Verzeichnis" = Hex 10). Das Byte-Muster dieser Einträge: Byte 1-11 Name + Extension Byte 12 Dateiattribute Byte 21-22 Start-Cluster (unter FAT16 leer, unter FAT32 Teil 2) Byte 23-24 Zeit Byte 25-26 Datum Byte 27-28 Start-Cluster (unter FAT32 Teil 1) Byte 29-32 Byte-Zahl der Datei Die Bytes 13 bis 20 bleiben entweder ungenutzt oder enthalten erweiterte Dateiattribute wie "letzter Zugriff" (nur unter Windows mit der VFAT, ½ "Noch eine FAT?", Seite 334). Mit Hilfe dieser Einträge stellt das System nun die Verbindung zwischen Dateinamen & Co. und dem entscheidenden Start-Cluster her. Eventuelle Folge-Cluster findet es in der FAT. Nur die Einträge für das Root-Verzeichnis haben ihren festen Platz nach der FAT, die Verwaltung aller Unterverzeichnisse erfolgt hingegen querbeet im Datenbereich der Festplatte. Ein Unterverzeichnis wird nämlich genauso angesteuert wie eine Datei - über den Start-Cluster. Benötigen Sie daher etwa die Datei C:\Win95\WIN.COM, beginnt die Suche im Root-Verzeichnis nach dem Dateinamen "Win95". Ist dieser vorhanden, springt das System zum Start-Cluster, der in Byte 27 und 28 des Eintrags "Win95" angegeben ist. In diesem Cluster findet es nun die Verzeichniseinträge für C:\Win95 und im Normalfall eben auch den Namen "WIN.COM". Jetzt gilt es wieder, die Nummer des Start-Clusters festzustellen und dann die Daten einschließlich aller eventuellen Folge-Cluster zu laden.

FAT & CLUSTER-GRÖSSEN So kommt es zur Fragmentierung der Dateien Für den Anwender stellen sich die Daten als hierarchisch gegliedert dar - tatsächlich handelt es sich um einen flachen linearen Byte-Strom, der nur durch Cluster-Verweise strukturiert ist. Abgesehen vom Root-Verzeichnis liegen Texte, Programme und Verzeichniseinträge in kunterbuntem Nebeneinander auf der Platte. Da DOS/Windows für neu hinzukommende Verzeichnisse und Dateien stets den ersten freien Cluster (den ersten FAT-Eintrag mit "00 00") verwendet, kommt es zwangsläufig zur Fragmentierung - übrigens nicht nur von Datei-Clustern, sondern auch von Verzeichniseinträgen. Sprich: Die Cluster, die zu einer Datei gehören, liegen nicht hintereinander, sondern unzusammenhängend über die Platte verstreut. Start-Cluster X verweist dann in der FAT nicht auf Folge-Cluster X+1, sondern etwa auf X+250, dieser dann vielleicht auf X+500. Technisch ist das kein Problem, bei starker Fragmentierung dauert jedoch die Suche länger. Ausgefeiltere Dateisysteme versuchen, der Fragmentierung selbsttätig entgegenzuwirken: So reserviert etwa NTFS (Windows NT) zumindest für Verzeichnisse Folge-Cluster für eventuelle weitere Einträge. Dadurch reduziert sich die Fragmentierung. Ein logischer Zusammenhang besteht ferner zwischen Cluster-Größe und Fragmentierung: Je kleiner die Cluster, desto größer die Wahrscheinlichkeit, daß eine Datei unzusammenhängend abgelegt werden muß. Bei 4-KB-Clustern wird eine 320-KB-Datei in 80 Teile, bei 32-KB-Clustern in zehn Teile zerlegt. Bei kleinen Clustern wird deshalb weniger Plattenplatz verschwendet - allerdings mit dem Nachteil, daß die Fragmentierung stärker ist. Gegen das Phänomen der Fragmentierung helfen spezielle Defragmentier-Programme (etwa das Windows-eigene DEFRAG.EXE). Das Prinzip ihrer Arbeitsweise ist an sich einfach: Das Programm geht die FAT Cluster für Cluster durch. Wenn es einen Verweis auf einen entfernten Cluster findet, räumt es den Inhalt des unmittelbar nachfolgenden Clusters vorübergehend ans freie Ende der Platte und holt dann den Inhalt des entfernten Clusters in den nunmehr freien Folge-Cluster. Das setzt sich so lange fort, bis alle vorhandenen Dateien und Verzeichniseinträge in kontinuierlich aufeinanderfolgenden Clustern unterbracht sind. Selbst bei geringer Fragmentierung bedeutet diese Aktion einen Massentransport von Daten und eine tiefgreifende Reorganisation von FAT und Platteninhalt - und das dauert. Die Programme erledigen die Arbeit noch am schnellsten, wenn sie relativ viel freien Platz zum Zwischenspeichern vorfinden und durch keine sonstigen Schreibzugriffe (im Multitasking) gestört werden. FAT12 - FAT16 - FAT32 Die Unterschiede in der Verwaltung Zwischen FAT12, das auf Disketten verwendet wird, FAT16 (Festplatten) und FAT32 (optional bei Festplatten unter Windows ab 95 B) gibt es nur einen geringen Unterschied - und zwar in der Anzahl der Bits für die Cluster-Zeiger. Das hat aber gravierende Auswirkungen: Wie beschrieben, besteht der Eintrag für den Start-Cluster in der Verzeichnistabelle aus 2 Bytes (27 und 28), also 16 Bits. Desgleichen verwendet die FAT in ihren Zeigern auf die Folge-Cluster je 2 Bytes pro Eintrag. Diese Aussage gilt jedoch nur für FAT16. FAT12 für Disketten begnügt sich mit 12 Bits (1,5 Bytes) in Verzeichnistabelle und FAT. FAT 32 stellt grundsätzlich 4 Bytes zur Verfügung, nutzt davon derzeit aber aufgrund eines internen Limits nicht alle 32, sondern nur 28 Bits. Die zusätzlich nötigen 2 Bytes im Verzeichniseintrag hat Microsoft auf die Bytes 21 und 22 gelegt, die bei FAT16 frei bleiben. Die Einträge in der FAT mussten natürlich ebenfalls auf 4 Bytes verdoppelt werden. Aus der Zahl der Bits für die Cluster-Zeiger errechnet sich die Zahl der Cluster, die das Dateisystem verwalten kann: FAT12: 212 = 4096 FAT16: 216 = 65.536 FAT32: 228 = 268.435.456 Das Maximum von 65.536 Einheiten unter FAT16 erweist sich bei einer höheren Plattenkapazität als Problem. Bei großen Platten führt es zu Clustern von 32 KB und damit zu extremer Platzverschwendung: Eine Datei mit 1 KB verbraucht beispielsweise einen ganzen Cluster, eine 34-KB-Datei deren zwei. Bei FAT16 gibt es noch ein gravierenderes Problem: Nachdem die Zahl der möglichen Sektoren auf 64 begrenzt ist und ein Sektor aus 512 Bytes besteht, sind Cluster-Größen über 32 KB nicht möglich. Somit sind 2 GB - 65.536 x 32 KB = 2.097.152 KB - für FAT16 die absolute Obergrenze. FAT32 kommt hingegen bei Platten bis 8 GB noch mit moderaten 4-KB-Clustern aus, mit 32-KB-Clustern sind Plattengrößen bis in den Terabyte-Bereich möglich.

NOCH EINE FAT? VFAT und die langen Namen Mit dem Kernel-Bestandteil VFAT. VXD, der bei der Installation in die Treibersammlung VMM32.VXD integriert wird, verbinden kundige Anwender die Fähigkeit des Dateisystems, lange Dateinamen zu verwalten. Das ist aber nur ein Aspekt: Die "virtuelle FAT" wurde schon mit Windows für Workgroups (WfW) 3.11 als VFAT.386 eingeführt, als von langen Dateinamen noch keine Rede war. VFAT war Hauptbestandteil des 32-Bit-Dateizugriffs, der WfW 3.11 gegenüber dem Vorgänger spürbar beschleunigte. Um den langsameren FAT-Zugriff über DOS-Interrupts zu ersetzen, sperrte VFAT die FAT gegen jeden anderen Zugriff und verwaltete alle Zugriffe exklusiv. Dieser im Verbund mit weiteren Protected-Mode-Komponenten wie Vcache leistungssteigernde Aspekt ist auch heute noch primäre Aufgabe von VFAT. Die Verwaltung langer Dateinamen und einiger erweiterter Dateiattribute (Änderungsdatum, letzter Zugriff) kam ab Windows 95 hinzu, ist aber technisch so fragil, daß man sich über ihr Funktionieren wundern mag: Auf der Basis der 32-Byte-Verzeichniseinträge waren lange Namen nur dadurch erreichbar, daß eine einzige Datei mehrere Einträge erhält. Damit das System zwischen echten Verzeichniseinträgen und LFN-Erweiterungen (LFN - Long File Name) unterscheiden kann, hat Microsoft für LFN-Einträge das Attribut 0F (binär= 00001111) erfunden - eine Kombination der Attribute "schreibgeschützt" (binär=1), "versteckt" (binär=10), "System" (binär=100) und "Label" (binär=1000). Die Erweiterung um die Attribute "Änderungsdatum" und "letzter Zugriff" war dagegen einfach, da in den Verzeichniseinträgen nach Byte 12 einige Bytes brachlagen. Logische Hilfsmittel PATH, Links & Registry Obwohl VFAT und Vcache das Aufsuchen und Bearbeiten (Löschen, Kürzen, Erweitern, Attributänderung) von Dateien wesentlich beschleunigen, ist Windows darauf ausgelegt, lange Suchwege von vornherein zu vermeiden. Wenn ein Anwender etwa Winword ohne explizite Pfadangabe aufruft, fällt es Windows nicht ein, alle Verzeichnisse nach diesem Namen zu durchsuchen - müßte es dabei doch locker 500 bis 1000 Start-Cluster ausfindig machen und dort jeweils nach "Winword" suchen. Dies geschieht praktisch nur im Suchen-Dialog oder nach "dir /s..." unter DOS. Im Normalfall liegt unter Windows die komplette Pfadangabe vor, was den Suchweg um den Faktor 100 verkürzt. So findet sich der Programmpfad in allen Verknüpfungen ebenso wie bei den registrierten Dateitypen in der Registry. Lediglich den sogenannten PATH hat Windows von DOS geerbt: Was in der AUTOEXEC.BAT nach "path=" eingetragen ist, geht das System in jedem Fall durch, bevor es "... nicht gefunden" meldet. Im Minimalfall handelt es sich um das Windows-Verzeichnis und das Unterverzeichnis "Command". Hinzu kommt - ohne explizite Erwähnung im PATH - das für Windows wichtigste Verzeichnis "System" mit den gemeinsam genutzten Systembibliotheken.

PC-WELT Marktplatz

726574