Moderne Betriebssysteme

Transkript

1

2 Andrew S. Tanenbaum Moderne Betriebssysteme 3., aktualisierte Auflage ein Imprint von Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario Sydney Mexico City Madrid Amsterdam

3 4 Dateisysteme seit seiner Einlagerung verändert worden ist). Diese Situation entspricht in vielerlei Hinsicht der beim Paging. Alle üblichen Seitenersetzungsalgorithmen, die in Kapitel 3 beschrieben wurden, wie FIFO, Second Chance und LRU, sind hier anwendbar. Ein erfreulicher Unterschied zwischen Paging und Caching ist, dass Cache-Referenzen relativ selten sind und es daher praktikabel ist, alle Blöcke in der exakten LRU-Reihenfolge in verketteten Listen aufzubewahren. In Abbildung 4.28 kann man erkennen, dass zusätzlich zu den Kollisionsketten, die an der Hashtabelle beginnen, noch eine bidirektionale Liste alle Blöcke in der Reihenfolge ihrer Verwendung durchläuft. Am Anfang dieser Liste steht der am längsten nicht verwendete Block, am Ende der zuletzt verwendete. Wenn auf einen Block zugegriffen wird, so kann er von seiner Position entfernt und an das Ende der Liste gesetzt werden. So lässt sich die exakte LRU-Reihenfolge aufrechterhalten. Leider gibt es eine Stolperfalle. Wir haben nun eine Situation erreicht, in der exaktes LRU möglich ist, und jetzt stellt sich heraus, dass dies gar nicht wünschenswert ist. Das Problem hat etwas mit Abstürzen und der Konsistenz des Dateisystems zu tun, mit Problemen also, die wir im vorigen Abschnitt diskutiert haben. Falls ein kritischer Block, zum Beispiel ein I-Node-Block, in den Cache geladen, modifiziert, nicht aber auf die Platte zurückgeschrieben wird, lässt ein Absturz das Dateisystem in einem inkonsistenten Zustand zurück. Wenn der I-Node-Block am Ende der LRU-Kette steht, so kann es schon eine Weile dauern, bis er den Anfang erreicht und auf die Platte zurückgeschrieben wird. Außerdem wird auf bestimmte Blöcke, wie eben die I-Node-Blöcke, nur selten zweimal innerhalb einer kurzen Zeitspanne zugegriffen. Diese Überlegungen führen zu einem veränderten LRU-Schema, das auf zwei Faktoren Rücksicht nimmt: 1. Ist es wahrscheinlich, dass der Block bald wieder gebraucht wird? 2. Ist der Block für die Konsistenz des Dateisystems entscheidend? Für die Beantwortung beider Fragen können die Blöcke in Kategorien wie I-Node-Blöcke, indirekte Blöcke, Verzeichnisblöcke, volle Datenblöcke und teilweise gefüllte Datenblöcke eingeteilt werden. Die Blöcke, die höchstwahrscheinlich nicht so bald wieder gebraucht werden, kommen eher an das Ende der LRU-Liste, damit deren Puffer schnell wieder verwendet werden können. Blöcke hingegen, die wahrscheinlich bald wieder benötigt werden, kommen an den Anfang der Liste, wo sie dann für lange Zeit bleiben werden. Die zweite Frage ist unabhängig von der ersten. Wenn der Block wichtig für die Konsistenz des Dateisystems ist (das sind im Wesentlichen alle Blöcke bis auf Datenblöcke) und modifiziert wurde, dann sollte er sofort zurück auf die Platte geschrieben werden, unabhängig davon, an welchem Ende der LRU-Liste er sich befindet. Damit lässt sich die Wahrscheinlichkeit, dass ein Absturz das Dateisystem zerstört, deutlich reduzieren. Da ein Benutzer schon unglücklich über die Zerstörung einer seiner Dateien nach einem Absturz sein wird, ist anzunehmen, dass er noch viel unglücklicher sein wird, wenn das gesamte Dateisystem verloren ist. 372

4 4.4 Dateisystemverwaltung und -optimierung Doch selbst mit dieser Maßnahme zur Erhaltung der Dateisystemintegrität ist es nicht sinnvoll, einen Datenblock zu lange im Cache zu halten. Denken Sie an jemanden, der sich damit abmüht, ein Buch auf einem PC zu verfassen. Auch wenn unser Autor den Editor regelmäßig anweist, die gerade bearbeitete Datei auf Platte zu schreiben, so ist es dennoch recht wahrscheinlich, dass alles im Cache bleibt und nicht auf die Platte geschrieben wird. Stürzt das System ab, so wird zwar die Dateisystemstruktur nicht zerstört, aber die Arbeit eines ganzen Tages kann verloren sein. Derartige Situationen führen meistens zu sehr unglücklichen Benutzern. Im Allgemeinen werden zwei Methoden angewandt, um dieses Problem anzugehen. UNIX geht den Weg über den Systemaufruf sync, der bewirkt, dass alle Blöcke sofort auf die Platte geschrieben werden. Wenn das System hochfährt, wird ein Programm, üblicherweise update genannt, gestartet, um im Hintergrund in einer Endlosschleife alle 30 Sekunden einen sync-aufruf abzusetzen. Folglich können nie mehr als 30 Sekunden an Arbeit durch einen Absturz verloren gehen. Windows verfügt mittlerweile über einen zu sync äquivalenten Systemaufruf namens FlushFileBuffer, doch in der Vergangenheit gab es stattdessen eine Strategie, die in einigen Punkten besser als der UNIX-Ansatz war (in einigen aber auch schlechter). Dabei wurde jeder modifizierte Block, sobald er geschrieben wurde, auf die Platte zurückgeschrieben. Cache-Speicher, bei denen alle veränderten Blöcke sofort auf die Platte zurückgeschrieben werden, nennt man Write-Through-Caches (im Deutschen auch als Cache mit Durchschreibestrategie bezeichnet). Allerdings erzeugen sie mehr Plattenein-/-ausgabe als die Varianten, die nicht direkt zurückschreiben. Den Unterschied zwischen den beiden Ansätzen kann man sehen, wenn ein Programm einen 1 KB großen Block Zeichen um Zeichen vollständig beschreibt. UNIX wird alle Zeichen im Cache sammeln und den Block entweder alle 30 Sekunden einmal oder wenn der Block aus dem Cache verdrängt wird auf die Platte schreiben. Bei einem Write-Through-Cache gib es für jedes geschriebene Zeichen einen Plattenzugriff. Natürlich benutzen die meisten Programme noch eine interne Zwischenspeicherung, so dass normalerweise nicht ein einzelnes Zeichen, sondern eine Zeile oder eine größere Einheit mit jedem write-aufruf geschrieben wird. Das Ergebnis dieses Unterschieds in der Cache-Verwaltungsstrategie ist, dass das bloße Entfernen einer Diskette aus einem UNIX-System ohne vorherige Ausführung von sync fast immer mit verlorenen Daten und oft auch mit einem zerstörten Dateisystem einhergeht. Mit einem Write-Through-Cache treten solche Probleme nicht auf. Diese unterschiedlichen Strategien entstanden aufgrund der jeweiligen Entwicklungsumgebungen: Als UNIX entwickelt wurde, waren alle Platten als Festplatten ausgelegt, die nicht entfernt werden konnten. Die ersten Windows-Dateisysteme hingegen entstanden in einer Welt der Disketten. Als die Festplatten zur Norm wurden, wurde der UNIX-Ansatz aufgrund seiner besseren Effizienz (aber schlechteren Zuverlässigkeit) ebenfalls zur Norm und wird heute auch in Windows für Festplatten verwendet. Allerdings beschreitet NTFS andere Wege (Journaling), wie wir bereits gesehen haben. 373

5 4 Dateisysteme Einige Betriebssysteme integrieren den Puffer-Cache im Seiten-Cache. Dies ist besonders attraktiv, wenn Memory-Mapped-Dateien unterstützt werden. Wenn eine Datei in den Speicher eingeblendet wird, dann sind eventuell einige ihrer Seiten bereits im Speicher, weil sie auf Anforderung eingelagert wurden. Solche Seiten unterscheiden sich kaum von Dateiblöcken im Puffer-Cache. In diesem Fall können sie genauso behandelt werden, mit einem einzelnen Cache sowohl für Dateiblöcke als auch für Seiten. Vorausschauendes Lesen von Blöcken Eine zweite Möglichkeit zur Verbesserung der wahrgenommenen Performanz des Dateisystems ist, die Blöcke in den Cache zu laden, noch bevor sie angefordert werden, und somit die Trefferrate zu erhöhen. Diese Idee basiert auf der Beobachtung, dass Dateien in der Regel sequenziell gelesen werden. Wird das Dateisystem angewiesen, Block k einer Datei einzulesen, so tut es dies, prüft aber anschließend, ob sichblock k + 1 schon im Cache befindet. Falls nicht, so wird ein Lesezugriff für Block k + 1 in der Hoffnung initiiert, dass dieser im Cache angekommen ist, wenn er benötigt wird. Zumindest wird er dann schon auf dem Weg dorthin sein. Natürlich funktioniert diese Strategie des vorausschauenden Lesens nur bei Dateien, die sequenziell gelesen werden. Wird auf eine Datei wahlfrei zugegriffen, so hilft die Methode nicht. Im Gegenteil, sie schadet dann sogar, da die Bandbreite der Platte durch das Lesen unnützer Blöcke und das Entfernen potenziell nützlicher Blöcke geringer wird. (Möglicherweise wird die Bandbreite sogar noch geringer, wenn die veränderten Blöcke auf die Platte zurückgeschrieben werden.) Um festzustellen, ob es den Aufwand wert ist, vorausschauend zu lesen, kann das Dateisystem die Zugriffsmuster jeder geöffneten Datei beobachten. Zum Beispiel könnte jeder Datei ein Bit zugeordnet werden, das darüber Auskunft gibt, ob sie sich im sequenziellen Zugriffsmodus oder im wahlfreien Zugriffsmodus befindet. Nach dem Motto Im Zweifel für den Angeklagten wird die Datei anfänglich in den sequenziellen Modus versetzt. Wann immer jedoch ein Plattenzugriff erfolgt, wird das Bit zurückgesetzt. Beginnen nun wieder sequenzielle Zugriffe, wird das Bit erneut gesetzt. Mit dieser Methode kann das Dateisystem vernünftige Annahmen darüber machen, ob vorausschauendes Lesen günstig ist oder nicht. Rät es hin und wieder falsch, ist das nicht gleich eine Katastrophe, es wird nur etwas von der Bandbreite der Platte verschwendet. Reduzierung der Bewegung des Plattenarms Caching und vorausschauendes Lesen sind nicht die einzigen Möglichkeiten zur Erhöhung der Performanz eines Dateisystems. Eine weitere wichtige Technik besteht darin, die Anzahl der Plattenarmbewegungen zu vermindern, indem man Blöcke, auf die wahrscheinlich der Reihe nach zugegriffen wird, nahe nebeneinander, vorzugsweise auf demselben Zylinder platziert. Wenn die Ausgabedatei geschrieben wird, so muss das Dateisystem die Blöcke bei Bedarf einen nach dem anderen belegen. Wenn die freien Blöcke in einer Bitmap verwaltet werden und die gesamte Bitmap im Arbeitsspeicher ist, dann ist es nicht allzu schwer, einen freien Block so zu wählen, 374

6 4.4 Dateisystemverwaltung und -optimierung dass dieser so nah wie möglich zum vorhergehenden Block liegt. Bei einer Freibereichsliste, die zum Teil auf der Platte steht, ist es viel schwerer, nahe zusammenliegende Blöcke zu finden. Doch auch mit einer Freibereichsliste kann man Blöcke gruppieren. Der Trick dabei ist, den Speicherplatz nicht in Blöcken, sondern in Gruppen von aufeinanderfolgenden Blöcken zu verwalten. Wenn alle Sektoren aus 512 Byte bestehen, so könnte das System 1-KB-Blöcke (zwei Sektoren) verwenden, den Speicherplatz jedoch in Einheiten von zwei Blöcken (vier Sektoren) belegen. Das ist nicht dasselbe, wie 2-KB-Blöcke zu verwenden, da der Cache immer noch 1 KB große Blöcke benutzt und der Datentransfer auch noch 1 KB beträgt. Das sequenzielle Lesen einer Datei auf einem ansonsten untätigen System würde die Anzahl der Plattenzugriffe um den Faktor 2 vermindern eine beträchtliche Verbesserung der Performanz. Eine Variation desselben Themas ist die Einbeziehung der rotierenden Positionierung. Wenn Blöcke belegt werden, dann versucht das System, die zusammenhängenden Blöcke einer Datei auf demselben Zylinder abzulegen. Ein anderer Engpass bezüglich der Performanz entsteht in Systemen, die I-Nodes oder etwas Ähnliches benutzen, denn der Lesezugriff selbst auf eine kleine Datei erfordert zwei Plattenzugriffe: einen auf den I-Node und einen auf den Block. Die übliche Position der I-Nodes ist in Abbildung 4.29(a) dargestellt. Hier liegen alle I-Nodes in der Nähe des Plattenanfangs, somit beträgt die durchschnittliche Entfernung zwischen dem I-Node und seinem Block ungefähr die Hälfte der Zylinderanzahl, was lange Zugriffszeiten zur Folge hat. sa I-Nodes liegen am Anfang der Platte Platte ist in Zylindergruppen aufgeteilt, wobei jede ihre eigenen I-Nodes besitzt Zylindergruppen a Abbildung 4.29: (a) Die Platzierung der I-Nodes am Anfang der Platte (b) Die Platte aufgeteilt in Zylindergruppen mit jeweils eigenen Blöcken und I-Nodes Eine einfache Verbesserung besteht darin, die I-Nodes in der Mitte der Platte anstatt am Anfang unterzubringen, was die durchschnittliche Suchzeit zwischen dem I-Node und dem ersten Block um den Faktor zwei reduziert. Ein anderes Vorgehen ist in Abbildung 4.29(b) dargestellt. Hier wird die Platte in Zylindergruppen aufgeteilt, jede mit ihren eigenen I-Nodes, Blöcken und Freibereichslisten (McKusick et al., b 375

7 4 Dateisysteme 1984). Wird eine Datei erzeugt, kann zwar prinzipiell jeder I-Node verwendet werden. Es wird jedoch versucht, einen Block in der gleichen Zylindergruppe zu finden, in der auch der I-Node steht. Falls keiner verfügbar ist, dann wird ein Block in einer benachbarten Gruppe verwendet Defragmentierung von Plattenspeicher Wenn das Betriebssystem anfänglich installiert wird, sind die benötigten Programme und Dateien, am Anfang der Platte nacheinander in direkter Folge abgelegt. Der gesamte freie Plattenbereich bildet eine einzige zusammenhängende Einheit, die hinter den installierten Dateien folgt. Aber mit der Zeit werden Dateien erzeugt und gelöscht und typischerweise wird die Platte stark fragmentiert, wodurch überall Dateien und Lücken entstehen. Folglich können die Blöcke, die für die Erzeugung einer neuen Datei benötigt werden, über die ganze Platte verteilt sein, was zu einer verringerten Performanz führt. Zur Wiederherstellung der Performanz können die Dateien hin und her geschoben werden, so dass sie wieder in aneinandergrenzenden Bereichen liegen und sich damit der gesamte freie Speicherplatz (oder zumindest der größte Teil davon) in einem einzelnen oder mehreren großen zusammenhängenden Teilen der Platte befindet. Windows hat für genau diesen Zweck ein Programm namens defrag eingerichtet. Windows-Benutzer sollten es regelmäßig laufen lassen. Defragmentierung funktioniert besser bei Dateisystemen, bei denen sehr viel Speicherplatz in einem zusammenhängenden Bereich am Ende der Partition frei ist. Damit ist das Defragmentierungsprogramm in der Lage, eine zerstückelte Datei vom Anfang der Partition auszuwählen und alle Blöcke dieser Datei auf den freien Platz zu kopieren. Durch diese Aktion wird ein zusammenhängender Speicherblock am Anfang der Partition frei, in dem die Originaldatei oder eine andere Datei an einem Stück untergebracht werden kann. Dieser Prozess kann dann mit dem nächsten freien Stück Speicherplatz wiederholt werden. Einige Dateien, darunter die Paging-Datei, die Hibernation-Datei und das Journaling- Log, können nicht verschoben werden, da der Verwaltungsaufwand hier viel größer als der Nutzen wäre. In einigen Systemen sind dies ohnehin zusammenhängende Bereiche mit fester Größe, bei denen also gar keine Defragmentierung nötig ist. Dieser Mangel an Mobilität stellt lediglich dann ein Problem dar, wenn sich die Dateien in der Nähe des Partitionsendes befinden und der Benutzer die Partitionsgröße reduzieren möchte. Die einzige Möglichkeit ist dann, all diese Dateien zu löschen, die Größe der Partition zu verändern und danach die Dateien neu zu erzeugen. Die Dateisysteme unter Linux (speziell ext2 und ext3) leiden im Allgemeinen weniger unter Defragmentierung als Windows-Systeme. Dies liegt an der Art und Weise, wie hier Plattenblöcke ausgewählt werden, so dass eine manuelle Defragmentierung selten nötig ist. 376

8 4.5 Beispiele von Dateisystemen 4.5 Beispiele von Dateisystemen In den folgenden Abschnitten werden wir verschiedene Dateisysteme beispielhaft betrachten. Die Spannweite reicht dabei von den recht einfachen bis zu den hochkomplizierten Systemen. Da die modernen UNIX-Dateisysteme und das Dateisystem von Windows Vista im Kapitel über Linux (Kapitel 10) und Windows Vista (Kapitel 11) behandelt werden, wollen wir hier nicht auf diese Systeme eingehen. Ihre Vorgänger werden wir jedoch untersuchen CD-ROM-Dateisysteme Als erstes Beispiel für ein Dateisystem betrachten wir die Dateisysteme auf CD-ROMs. Diese Systeme sind besonders einfach strukturiert, da sie für einmal beschreibbare Medien entwickelt wurden. Unter anderem besitzen sie keine Mittel, um über die freien Blöcke zu wachen, denn auf einer CD-ROM können nach ihrer Herstellung keine Dateien mehr gelöscht oder hinzugefügt werden. Im Folgenden werden wir einen Blick auf das Hauptdateisystem der CD-ROM werfen und auch zwei Erweiterungen dafür betrachten. Ein paar Jahre nach dem Debüt der CD-ROM wurde die CD-R (CD Recordable) eingeführt. Anders als bei der CD-ROM ist es hier möglich, Dateien nach dem ersten Brennen hinzuzufügen, aber diese werden einfach am Ende der CD-R angehängt. Dateien werden nie wirklich gelöscht (auch wenn das Verzeichnis aktualisiert werden kann, um vorhandene Dateien zu verstecken). Durch dieses Nur-Anhängen wurden die grundsätzlichen Eigenschaften des Dateisystems nicht verändert. Insbesondere befindet sich der gesamte freie Speicherbereich weiterhin in einem zusammenhängenden Stück am Ende der CD. Das ISO-9660-Dateisystem Der gebräuchlichste Standard für CD-ROM-Dateisysteme wurde als internationaler Standard im Jahre 1988 unter dem Namen ISO 9660 anerkannt. Praktisch jede CD- ROM, die sich zurzeit auf dem Markt befindet, ist zu diesem Standard kompatibel, manchmal mit den Erweiterungen, die weiter unten vorgestellt werden. Eines der Ziele dieses Standards war es, jede CD-ROM auf jedem Computer, unabhängig von der benutzten Byte-Ordnung und dem jeweiligen Betriebssystem lesbar zu machen. Als Konsequenz wurde das Dateisystem in einigen Bereichen eingeschränkt, um auch für das schwächste Betriebssystem (wie MS-DOS) lesbar zu sein. CD-ROMs besitzen keine konzentrischen Zylinder wie die magnetischen Platten, sondern stattdessen eine einzige kontinuierliche Spirale, die die Bits in einer linearen Sequenz enthält (obwohl Suchsprünge auf der Spirale möglich sind). Die Bits entlang der Spirale sind in logische Blöcke (auch logische Sektoren genannt) von Byte unterteilt. Einige davon sind für Präambeln, Fehlerkorrektur und anderes Beiwerk vorgesehen. Die Datenportion beträgt in jedem logischen Block Byte. Wenn die CDs für Musik benutzt werden, dann haben sie sogenannte Einleitungsbereiche (leadin) 377

9 4 Dateisysteme und Schlussbereiche (leadout) sowie Lücken zwischen den Tracks. Dies ist etwas, das es bei Daten-CDs nicht gibt. Oft wird die Position eines Blocks auf der Spirale in Minuten und Sekunden angegeben. Diese Angabe kann in eine lineare Blocknummer über den Umrechnungsfaktor von 1 s = 75 Blöcke umgewandelt werden. ISO 9660 unterstützt Mengen von CD-ROMs mit CDs pro Menge. Jede individuelle CD-ROM kann ebenfalls in logische Einheiten (Partitionen) unterteilt werden. Wir werden uns im Folgenden aber auf ISO 9660 für eine einzelne, nicht partitionierte CD- ROM konzentrieren. Jede CD-ROM beginnt mit 16 Blöcken, deren Funktion nicht durch den ISO-9660-Standard definiert ist. Der Hersteller könnte diese Region nutzen, um z.b. ein Boot-Programm zur Verfügung zu stellen, mit dessen Hilfe der Computer von der CD-ROM aus hochgefahren werden kann, aber auch andere Verwendungszwecke sind denkbar. Als Nächstes kommt ein Block, der den Primärvolumendeskriptor (primary volume descriptor) enthält, welcher generelle Informationen über die CD-ROM enthält. Unter diesen Informationen finden sich der Systemidentifikator (32 Byte), der Volumenidentifikator (32 Byte), der Herausgeberidentifikator (128 Byte) und der Datenvorbereitungsidentifikator (128 Byte). Die Hersteller können diese Felder beliebig füllen. Zum Erhalten der Plattformunabhängigkeit muss lediglich beachtet werden, dass nur Großbuchstaben, Zahlen und eine sehr kleine Anzahl von Sonderzeichen benutzt werden. Der Primärvolumendeskriptors enthält außerdem die Namen von drei Dateien, die eine Zusammenfassung, die Urheberrechtsbestimmungen bzw. bibliografische Informationen umfassen können. Zusätzlich sind einige Schlüsselwerte gespeichert, wie die logische Blockgröße (normalerweise 2.048, es sind jedoch auch 4.096, und größere Potenzen von 2 in bestimmten Fällen erlaubt), die Anzahl der Blöcke auf der CD-ROM und das Erzeugungs- und Haltbarkeitsdatum der CD-ROM. Schließlich beinhaltet der Primärvolumendeskriptor auch noch einen Verzeichniseintrag für das Wurzelverzeichnis, der darüber informiert, wo dieses auf der CD-ROM zu finden ist (d.h., ab welchem Block es beginnt). Von diesem Verzeichnis aus kann der Rest des Dateisystems lokalisiert werden. Zusätzlich zum Primärvolumendeskriptor kann eine CD-ROM noch einen weiteren Volumendeskriptor besitzen. Er enthält ähnliche Informationen wie der Primärvolumendeskriptor, aber das soll uns hier nicht weiter beschäftigen. Das Wurzelverzeichnis und auch alle anderen Verzeichnisse bestehen deshalb aus einer variablen Anzahl von Einträgen, deren jeweils letzter eine Bit-Markierung für das Ende enthält. Die Verzeichniseinträge selbst sind auch von variabler Länge. Jeder Eintrag besteht aus zehn bis zwölf Feldern. Einige davon sind in ASCII, andere sind numerische Binärfelder. Die binären Felder sind doppelt codiert, einmal im Little-Endian- Format (beispielsweise auf dem Pentium üblich) und einmal im Big-Endian-Format (zum Beispiel auf SPARCs gebräuchlich). Folglich benötigt eine 16-Bit-Zahl 4 Byte und eine 32-Bit-Zahl 8 Byte. Die Verwendung dieser redundanten Codierung war nötig, um die Gefühle verschiedener Personen bei der Entwicklung dieses Standards nicht zu verletzen. Hätte der 378

10 4.5 Beispiele von Dateisystemen Standard Little-Endian diktiert, so hätten sich die Menschen von Firmen mit Big- Endian-Produkten wie Bürger zweiter Klasse gefühlt und den Standard nicht akzeptiert. Der emotionale Gehalt einer CD-ROM kann also exakt quantifiziert und gemessen werden: Es ist der verschwendete Platz in Kilobyte/Stunde. Das Format eines ISO-9660-Verzeichniseintrages ist in Abbildung 4.30 abgebildet. Da die Verzeichniseinträge variable Längen haben, ist das erste Feld ein Byte, das über die Länge des Eintrages Auskunft gibt. Um Mehrdeutigkeiten zu vermeiden, ist dieses Byte so definiert, dass das höchstwertige Bit links steht. sa Padding Bytes Ort der Datei Länge der erweiterten Attribute Länge des Verzeichniseintrags Abbildung 4.30: Der ISO-9660-Verzeichniseintrag Dateigröße Datum und Zeit CD-Nr. L Dateiname Sys Wahlweise können Verzeichniseinträge erweiterte Attribute besitzen. Falls diese Möglichkeit genutzt wird, dann bestimmt das zweite Byte die Länge der erweiterten Einträge. Als Nächstes kommt der Startblock der Datei selbst. Dateien werden als eine zusammenhängende Menge von Blöcken abgespeichert, so dass die Position einer Datei ausschließlich durch den Startblock und die Größe der Datei, die im nächsten Feld angegeben wird, bestimmt ist. Das Datum und der Zeitpunkt, an dem die CD-ROM aufgenommen wurde, werden im nächsten Feld abgelegt, wobei separate Bytes für Jahr, Monat, Tag, Stunde, Minute, Sekunde und Zeitzone benutzt werden. Die Jahre beginnen mit der Zählung bei 1900 das bedeutet, dass die CD-ROMs ein Jahr-2156-Problem haben werden, da das dem Jahr 2155 folgende Jahr 1900 ist. Das Problem hätte verzögert werden können, wenn man den Beginn auf das Jahr 1988 (das Jahr, in dem der Standard eingeführt wurde) gelegt hätte. Damit hätte man das Problem auf das Jahr 2244 verschieben können. Ein Gewinn von 88 Jahren hätte schließlich auch schon etwas gebracht. Das Flags-Feld beinhaltet einige weitere Bits, darunter ein Bit zum Verstecken von Einträgen (eine Funktion, die von MS-DOS kopiert wurde), ein Bit zur Unterscheidung zwischen Dateieinträgen und Verzeichniseinträgen, ein Bit, um die Verwendung der erweiterten Attribute zu ermöglichen, und schließlich ein Bit, um den letzten Eintrag eines Verzeichnisses zu markieren. Es existieren noch einige andere Bits in diesem Feld, die uns hier jedoch nicht weiter interessieren. Das nächste Feld beschäftigt sich mit verschachtelten Dateistücken, und zwar in einer Weise, die in der einfachsten Version von ISO 9660 nicht angewendet wird. Wir werden dieses Feld daher nicht weiter behandeln. Das nächste Feld bestimmt die CD-ROM, auf der die Datei zu finden ist. Es ist erlaubt, dass ein Verzeichniseintrag auf einer CD-ROM sich auf eine Datei auf einer anderen Flags Verschachtelung Basisname Erw. Vers. ; nr. 379

11 4 Dateisysteme CD-ROM innerhalb der Menge bezieht. So ist es möglich, ein Hauptverzeichnis auf der ersten CD-ROM zu erstellen, das alle Dateien auf allen CD-ROMs der Menge auflistet. Das Feld L in Abbildung 4.30 gibt die Größe des Dateinamens in Byte an, gefolgt vom Dateinamen selbst. Der Dateiname besteht aus einem Basisnamen, einem Punkt, einer Erweiterung, einem Semikolon und einer binären Versionsnummer (1 oder 2 Byte). Der Basisname und die Erweiterung dürfen Großbuchstaben, die Ziffern von 0 bis 9 und den Unterstrich verwenden. Alle anderen Zeichen sind verboten, um sicherzustellen, dass jeder Computer mit jedem Dateinamen umgehen kann. Der Basisname kann bis zu acht Zeichen lang sein, die Erweiterung bis zu drei Zeichen. Diese Entscheidungen wurden durch die Notwendigkeit der Kompatibilität zu MS-DOS diktiert. Ein Dateiname kann mehrfach in einem Verzeichnis vorkommen, solange jeder davon eine unterschiedliche Versionsnummer hat. Die letzten beiden Felder sind nicht immer vorhanden. Das Feld Padding soll dafür sorgen, dass jeder Verzeichniseintrag eine gerade Anzahl von Bytes hat. Das bewirkt, dass die numerischen Felder der nachfolgenden Einträge auf 2-Byte-Grenzen liegen. Falls die Anpassung benötigt wird, benutzt man 0 Byte. Schließlich gibt es noch das Feld System use. Seine Funktion und Größe sind bis auf die Vorgabe undefiniert, dass es eine gerade Anzahl von Bytes enthalten muss. Die einzelnen Systeme benutzen dieses Feld auf unterschiedliche Weise. Der Macintosh bewahrt hier zum Beispiel die Finder-Flags auf. Die Einträge innerhalb eines Verzeichnisses werden in alphabetischer Reihenfolge aufgelistet. Ausnahmen bilden die zwei ersten Einträge. Der erste Eintrag ist das Verzeichnis selbst. Der zweite ist für seinen Vorgänger. In diesem Sinne sind diese Einträge den UNIX-Einträgen. und.. ähnlich. Die Dateien selbst müssen nicht in der Ordnung der Verzeichnisse vorliegen. Es gibt kein explizites Limit für die Anzahl der Einträge in einem Verzeichnis. Es gibt aber eine Grenze für die Schachtelungstiefe. Das Maximum für die Tiefe der Verschachtelung in einem Verzeichnis ist acht. Diese Grenze wurde willkürlich gewählt, um einige Implementierungen zu vereinfachen. ISO 9660 definiert die sogenannten drei Ebenen. Ebene 1 ist die restriktivste Ebene, sie spezifiziert wie beschrieben die Beschränkung der Dateinamen auf 8+3 Zeichen und verlangt, dass alle Dateien zusammenhängend sind. Außerdem setzt sie die Verzeichnisnamen auf höchstens acht Zeichen ohne Endung fest. Die Verwendung dieser Ebene maximiert die Chancen, dass die CD-ROM von jedem Computer gelesen werden kann. Ebene 2 lockert die Längenrestriktion. Sie gestattet es, dass die Namen der Dateien und Verzeichnisse bis zu 31 Zeichen lang sein dürfen, jedoch immer noch vom gleichen Zeichensatz stammen. Ebene 3 verwendet die gleichen Grenzen für die Namenslänge wie Ebene 2, lockert jedoch teilweise die Voraussetzung, dass die Dateien zusammenhängend sein müssen. In dieser Ebene kann eine Datei aus verschiedenen Sektionen (Erweiterungen) bestehen, wovon jede eine zusammenhängende Menge von Blöcken darstellt. Die gleiche 380

12 4.5 Beispiele von Dateisystemen zusammenhängende Blockmenge kann mehrmals in einer Datei vorkommen und auch in zwei oder mehreren Dateien auftreten. Falls große Datenteile in verschiedenen Dateien wiederholt werden, so stellt die Ebene 3 etwas an Platzoptimierung zur Verfügung, da die Daten nicht gezwungenermaßen mehrmals vorhanden sein müssen. Rock-Ridge-Erweiterungen Wie wir gesehen haben, ist ISO 9660 in vielerlei Hinsicht höchst restriktiv. Kurz nachdem der Standard herausgekommen war, arbeiteten die Leute der UNIX-Gemeinde an einer Erweiterung, um es zu ermöglichen, dass das UNIX-Dateisystem auf einer CD- ROM abgebildet werden kann. Diese Erweiterung wurde Rock Ridge genannt, nach einer Stadt im Kinofilm Blazing Saddles (mit Gene Wilder). Wahrscheinlich mochte einer der Mitglieder des Komitees diesen Film. Die Erweiterungen benutzen das Feld System use, um die Rock-Ridge-CD-ROMs auf jedem Computer lesbar zu machen. Alle anderen Felder behalten ihre Bedeutung gemäß ISO Jedes System, das die Rock-Ridge-Erweiterung nicht kennt, ignoriert die Einträge in System use und sieht eine normale CD-ROM. Die Erweiterungen sind in die folgenden Felder aufgeteilt: 1. PX POSIX-Attribute 2. PN Haupt- und Nebengerätenummern 3. SL Symbolischer Link 4. NM Alternativer Name 5. CL Position des Nachfolgers (Child Location) 6. PL Position des Vorgängers (Parent Location) 7. RE Relokation (Ladevorgang) 8. TF Zeitstempel Das PX-Feld enthält die Standard-UNIX-Zugriffsbits rwxrwxrwx für Eigentümer, Gruppe und andere. Es enthält außerdem die anderen Bits, die im Moduswort enthalten sind, also unter anderem die SETUID- und SETGID-Bits. Damit auch spezielle Treiberdateien (raw device) auf einer CD-ROM vorhanden sein können, gibt es das PN-Feld. Es enthält die Haupt- und Nebengerätenummern der Datei. Auf diese Art können die Inhalte aus dem /dev-verzeichnis auf eine CD geschrieben und später wiederhergestellt werden. Das SL-Feld ist für symbolische Links. Es gestattet einer Datei eines Dateisystems, auf eine Datei eines anderen Dateisystems zuzugreifen. Das wahrscheinlich wichtigste Feld ist NM. Damit kann der Datei ein zweiter Name zugeordnet werden. Dieser Name unterliegt nicht der Zeichensatz- und Längenbeschränkungen von ISO 9660, wodurch es möglich wird, beliebige UNIX-Dateinamen auf einer CD-ROM darzustellen. 381

13