Betriebssysteme 5. Dateisysteme II. Peter Altenbernd Dateisysteme II Betriebssysteme WS 2010/11 Hochschule Darmstadt

Transkript

1 Betriebssysteme 5. Dateisysteme II 1

2 Übersicht 1. Ziel des Kapitels 2. Implementierung von Dateisystemen 3. Organisation von Dateisystemen 4. Leistungsoptimierung 5. Konsistenz von Dateisystemen 6. Linux Dateisysteme 2

3 1. Ziel dieses Kapitels Dieser Teil beschreibt den Aufbau und die Realisierung von Dateisystemen insbesondere am Beispiel von Linux/Unix. Relevante Abschnitte im Buch [1] Abschnitt Abschnitte 6.3 und 6.4 3

4 1. Ziel dieses Kapitels Jede Anwendung muss Informationen speichern und abrufen können. Üblicherweise geschieht dies mit Hilfe von Dateien, d.h. Organisationseinheiten von Daten, die auf externen Medien gespeichert werden. Dafür gibt es folgende Gründe: Die Kapazität des Adressraums ist zu klein. Die Dateien des Adressraums sind nicht persistent, d.h. sie gehen verloren. Der Zugriff auf gemeinsam genutzte Daten ist einfacher und kann entsprechend geschützt werden (Benutzersicht) Die Existenz einer Datei ist unabhängig davon, ob ein Programm gerade läuft. Auf entfernte bzw. weitere Datenträger zugegriffen werden. Die Aufgaben des Betriebssystems hierbei sind: Verwaltung, d.h. Strukturierung und Namensgebung Zugriff, d.h. Benutzung und Schutz Darstellung gegenüber dem Benutzer Ein- und Aushängen von Datenträgern 4

5 2. Implementierung von Dateisystemen Ein Dateisysteme verwaltet sondern Zuordnungseinheiten, die Blöcke genannt werden. Im Folgenden werden verschiedene Möglichkeiten gezeigt, wie welche Plattenblöcke mit welchen Dateien in Verbindung zu bringen sind. Danach wird auf andere Aspekte der Implementierung von Dateisystemen eingegangen. 2.1 Zusammenhängende Belegung Hierbei werden Dateien hintereinander auf die Platten geschrieben. 5

6 2. Implementierung von Dateisystemen Vorteile einfach, denn die Dateiblöcke können durch Kenntnis der Adresse des Anfangsblocks und der Anzahl der Folgeblöcke adressiert werden. eine Komplette Datei kann mit nur einer Operation von der Platte gelesen werden. Nachteil Fragmentierung Eine Verwendung dieses Ansatzes macht insbesondere bei CD-ROMs Sinn. 6

7 2. Implementierung von Dateisystemen 2.2 Belegung durch verkettete Listen Hierbei wird jede Datei als verkettete Liste von Plattenblöcken gespeichert. 7

8 2. Implementierung von Dateisystemen Dabei entsteht keine Fragmentierung. Allerdings ist der wahlfreie Zugriff sehr langsam, da alle davor liegenden Blöcke besucht werden müssen. Eine alternative Umsetzung davon ist eine Datei-Allokationstabelle (FAT), die in den Hauptspeicher gelegt wird. Dadurch wird der wahlfreie Zugriffe (geringfügig) beschleunigt. Diese Tabelle kann allerdings sehr groß werden (Frage: Wie groß?). 8

9 2. Implementierung von Dateisystemen 2.3 I-Nodes Unix-Dateisysteme sind nach einem anderen Prinzip aufgebaut. Es gibt zwar viele verschiedene Dateisysteme unter Unix, die prinzipielle Funktionsweise ist jedoch immer gleich. Dieses Prinzip beruht auf einer Datenstruktur names I-Nodes. Ein I-Node enthält zu jeder Datei die zugehörigen Attribute (Größe usw.) und eine feste Anzahl Datenträgeradressen der verwendeten Blöcke der Datei. Benutzt die Datei weniger Platz, sind die Felder einfach leer. Jedes I-Node wird mit einer eindeutigen Nummer in Verbindung gebracht 9

10 2. Implementierung von Dateisystemen Vorteile: Das I-Node muss nur dann im Speicher stehen, wenn die Datei geöffnet ist. Im Vergleich zu einer FAT wird weniger Speicherplatz benötigt. Frage: Wie viel Platz wird benötigt? Nachteil: Die Größe einer Datei ist limitiert auf eine bestimmte Anzahl von Blöcken. Dies lässt sich allerdings verbessern, indem Indirektionsblöcke benutzt werden: Ist die Datei z.b. größer als 10 Blöcke (also größer als 10*1024 oder 10*2048 oder 10*512), so enthält das nächste Feld des I-Nodes eine Adresse eines Blockes, der wiederum bis zu 128 Adressen anderer Blöcke enthalten kann. Sollte das auch noch nicht ausreichen, so enthält der nächste I-Node-Eintrag eine Adresse eines Zweifach-Indirektionsblocks, eines Blocks, der bis zu 128 Adressen auf Blöcke mit wiederum 128 Adressen enthält. Falls auch das noch zu wenig sein sollte, enthält der nächste Eintrag die Adresse eines Blockes, der wiederum 128 Adressen von ZweifachIndirektionsblöcken enthalten kann. So sind Dateigrößen von 1, 2 oder 4 Gigabyte (je nach Blockgröße von 512, 1024 oder 2048 Byte) möglich. 10

11 2. Implementierung von Dateisystemen I-Nodes mit Dreifach-Indirektionsblöcken: 11

12 2. Implementierung von Dateisystemen Das Format eines typischen I-Nodes sieht somit etwa so aus: Typ und Zugriffsrechte Anzahl der Hardlinks Benutzernummer (UID) Gruppennummer (GID) Größe der Datei in Bytes Datum der letzten Veränderung (mtime) Datum der letzten Statusänderung (ctime) Datum des letzten Zugriffs (atime) Adresse von Datenblock 0... Adresse von Datenblock 9 Adresse des ersten Indirektionsblocks Adresse des Zweifach Indirektionsblocks Adresse des Dreifach Indirektionsblocks Zu beachten ist, dass der Dateiname selbst nicht im I-Node auftaucht. Ein INode ist also nur die Referenz auf die Datenblöcke, die eine Datei benutzt und der Ort, an dem die Attribute wie Eigentümer, Gruppe, Größe und Zugriffsdaten gespeichert sind. 12

13 2. Implementierung von Dateisystemen 2.4 Implementierung von Verzeichnissen Die Hauptfunktion eines Verzeichnisses ist es, den Namen einer Datei auf die benötigte Information zum Auffinden der zugehörigen Daten (Nr. des ersten Blocks bei einer FAT bzw. Nr. des I-Nodes) abzubilden. Die zu einer Datei gehörigen Attribute (z.b. Eigentümer, Entstehungszeit) werden ebenfalls direkt im Verzeichnis abgelegt. Werden I-Nodes benutzt, können die Attribute auch in den I-Nodes abgespeichert werden, was die Verzeichnis-Einträge kürzer macht. In einem einfachen DS (wie MS-DOS) besteht ein Verzeichnis aus einer Liste (fester Größe) mit Einträgen fester Größe (8.3-Prinzip). Will man längere Dateinamen unterstützen, besteht die Möglichkeit, ein höheres Limit zu setzen (z.b. 255 Zeichen Frage: Nachteil?) oder eine dynamische Datenstruktur (Heap) zu benutzen. Natürlich ist der Verwaltungsaufwand dafür höher. 13

14 2. Implementierung von Dateisystemen Soll eine bestimmte Datei in einem Verzeichnis gefunden werden, muss das Verzeichnis linear durchsucht werden, d.h. vom Anfang bis zum Ende, was für sehr große Verzeichnisse sehr zeitaufwendig ist. Ein Weg, diese Suche zu beschleunigen, ist es, Hash-Tabellen oder Binäre Suchbäume für die Verwaltung der Dateinamen zu verwenden ( später). Sowohl bei FAT- als auch bei I-Node-basierten Dateisystemen können Verzeichnisse selbst als Dateien abgelegt werden, so dass es keine (ungewollten) Beschränkungen gibt. Jedes Verzeichnis auch das Wurzelverzeichnis ist unter Unix also nichts anderes als eine Datei, deren Inhalt einfach die Dateinamen der enthaltenen Dateien samt ihren I-NodeNummern enthält. Ein Attribut weist dabei darauf hin, dass es sich um ein Verzeichnis handelt. Je nach verwendetem Dateisystem liegt das Wurzelverzeichnis auf einem festgelegten I-Node (meistens 1 oder 2). Grundsätzlich ist es aber dem Dateisystem bekannt, welcher I-Node das Wurzelverzeichnis enthält ( Superblock). 14

15 2. Implementierung von Dateisystemen Beispiel: Zugriff auf /usr/ast/mbox Frage: Auf welchem I-Node liegt das Wurzelverzeichnis? 15

16 2. Implementierung von Dateisystemen 2.5 Implementierung von Links Durch Links wird aus einem Datei-Baum ein gerichteter azyklischer Graph. Die Umsetzung von Hard-Links also von Dateien mit mehreren Namen mit Hilfe von I-Nodes ist einfach: Es wird die Anzahl der Verweise auf eine Datei gezählt, denn es handelt sich ja nur um verschiedene Namenseinträge, die eben dieselbe I-Node-Nummer besitzen. Beispiel: Problem: Die Datei ist am Ende immer noch im Besitz von C. Bei Symbolischen Links (Soft-Links) besteht der Verweis aus einer Textdatei, die den Pfadnamen enthält. Das Entfernen des Soft-Links berührt die verwiesene Datei also in keiner Weise. Das Kopieren von Dateibäumen wird durch Links erschwert. 16

17 2. Implementierung von Dateisystemen 2.6 Der Superblock Ein Unix-Dateisystem besitzt einen so genannten Superblock, d.h. einen Block, der die grundlegende Information (Schlüssel-Parameter) zum Dateisystem enthält. Einige wichtige Daten des Superblocks sind: Die Größe des Dateisystems in Blöcken Die Größe der Blöcke in Bytes Zeiger auf den ersten freien Datenblock Zeiger auf erste freie I-Node Verschiedene Statusbits (Flags) Auch hier unterscheiden sich die verschiedenen Unix-Dateisysteme von einander, was an zusätzlichen Informationen im Superblock gespeichert ist. Das Wesentliche an dieser Struktur ist, dass der Superblock beim Mounten eines Dateisystems in den Speicher gelesen wird und alle Veränderungen dort vorgenommen werden. Erst beim Wiederabhängen des Dateisystems werden diese Veränderungen physikalisch auf der Platte gespeichert, so dass es nach einem Systemabsturz zu Inkonsistenzen kommen kann. 17

18 2. Implementierung von Dateisystemen 2.7 Verwaltung von Blöcken Wie bei der Verwaltung des Hauptspeichers ist die Auswahl der geeigneten Granularität eine schwierige Angelegenheit: Bei größeren Blöcken wird Platz verschenkt, denn kleine Dateien oder Teile davon benötigen benötigen immer einen ganzen Block. Bei kleinen Blöcken ergibt sich eine größere Zerstückelung der Dateien, so dass längere Suchzeiten zu erwarten sind. Multimedia Betriebssysteme mit sehr großen Dateigrößen haben diesbezüglich andere Anforderungen als normale Anwendungen. 18

19 2. Implementierung von Dateisystemen Der noch verfügbare Plattenplatz kann als Liste oder Bitmap verwaltet werden: 19

20 3. Organisation von Dateisystemen 3.1 Partitionen und Wechseldatenträger Dateisysteme werden auf Platten gespeichert, die sich in mehrere Partitionen mit unterschiedlichen Dateisystemtypen einteilen lassen. Jede Partition ist etwa wie folgt aufgeteilt: 20

21 3. Organisation von Dateisystemen Ein Unix-System fasst alle Partitionen und angeschlossenen Laufwerke zu einem Dateibaum zusammen. Physikalisch bleiben die Daten auf den entsprechenden Partitionen bzw. Laufwerken. Mit dem Befehl mount (montiere) werden dabei die Partitionen an einem bestimmten Punkt des Dateisystems eingehängt. Als ein solcher Mountpoint dient jeweils ein leeres Verzeichnis. (Falls das Verzeichnis nicht leer ist, so wird der Inhalt während des Zustands, in dem ein anderes Laufwerk in das Verzeichnis gemountet ist, versteckt. Nach dem Wiederabhängen des Laufwerks mit dem Befehl umount wäre der Inhalt des Verzeichnisses wieder unverändert vorhanden). 21

22 3. Organisation von Dateisystemen In der Regel werden alle Partitionen, die verwendet werden sollen, bereits während des Bootvorgangs automatisch gemountet. Dazu muss das System aber eine entsprechende Bauanleitung besitzen, die klärt, in welche Verzeichnisse welche Partitionen eingehängt werden sollen. Unter Linux liegt diese Bauanleitung in der Datei /etc/fstab und enthält gleichzeitig auch Angaben zu den Partitionen oder Laufwerken beinhalten, die nicht automatisch gemountet werden sollen, wie etwa Wechseldatenträger oder CD-Rom-Laufwerke, z.b.: $ cat /etc/fstab /dev/hda6 / reiserfs /dev/hda1 /windows/c ntfs /dev/hda2 /windows/d vfat /dev/hda5 swap swap devpts /dev/pts devpts proc /proc proc usbfs /proc/bus/usb usbfs sysfs /sys sysfs /dev/dvdram /media/dvdram subfs $ acl,user_xattr 1 1 ro,users,gid=users,umask=0002,nls=utf8 0 0 users,gid=users,umask=0002,iocharset=utf8 0 0 pri= mode=0620,gid=5 0 0 defaults 0 0 noauto 0 0 noauto 0 0 fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=u 22

23 3. Organisation von Dateisystemen Die Zeilen haben folgendes Format: Gerätedatei Mountpoint Dateisystemtyp Optionen Dump Reihenfolge Gerätedatei: Hier steht die Gerätedatei des blockorientierten Geräts, das die Partition oder das Laufwerk bezeichnet. Dabei kann es sich auch um ein Netzlaufwerk (NFS) handeln, z.b. hal.mydomain.de:usr/public Mountpoint: Hier steht das Verzeichnis, in das die Partition oder das Laufwerk eingehängt werden soll. Dateisystemtyp: Hier wird der Typ des Dateisystems angegeben, das diese Partition bzw. dieses Laufwerk enthält. Der Kernel muss das jeweilige Dateisystem unterstützen, sonst kann es nicht gemountet werden. 23

24 3. Organisation von Dateisystemen Jedes Mal, wenn ein Dateisystem mit mount in den Dateibaum gehängt wurde, wird dieses Dateisystem in der Datei /etc/mtab eingetragen bzw. bei umount wieder entfernt. Wird der Befehl mount ohne jeden Parameter eingegeben, so liest er diese Datei und gibt den Inhalt in etwas aufbereiteter Form auf dem Bildschirm (genauer der Standard-Ausgabe) aus, z.b: $ mount /dev/hda6 on / type reiserfs (rw,acl,user_xattr) proc on /proc type proc (rw) tmpfs on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hda1 on /windows/c type ntfs (ro,noexec,nosuid,nodev,gid=100,umask=0002,nls=utf8) /dev/hda2 on /windows/d type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,iocharset /dev/hdc on /media/dvdram type subfs (ro,nosuid,nodev,fs=cdfss,procuid,iocharset=utf8) usbfs on /proc/bus/usb type usbfs (rw)1 $ 24

25 3. Organisation von Dateisystemen 3.2 Anlegen von Dateisystemen Bevor eine Partition benutzt werden kann, muss auf ihr zunächst ein Dateisystem angelegt werden (Formatierung). Der Befehl, mit dem dieser Vorgang gestartet wird ist mkfs (Make Filesystem). Folgendes Kommando legt ein Dateisystem auf einer Diskette an: $ /etc/mkfs /dev/dsk/f0q15dt 2200 $ Der letzte Parameter des mkfs-kommandos legt die Anzahl der Blöcke fest, aus denen das Filesystem besteht. 25

26 4. Leistungsoptimierung 4.1 Caching für Dateien Hier beschreibt Cache eine Ansammlung von Blöcken, die logisch auf der Platte stehen, jedoch aus Gründen der Performance im Speicher gehalten werden. Es können verschiedene Algorithmen verwendet werden, um den Cache zu verwalten. Üblicherweise wird geprüft, 1. ob der benötigte Block schon im Cache liegt. 2. Ist das nicht der Fall, wird dieser nachgeladen und 3. es wird ggf. ein anderer Block verdrängt und zurück geschrieben. Es herrscht also eine ähnliche Situation wie beim Paging der SpeicherVerwaltung, so dass auch hier die üblichen Seitenersetzungverfahren eingesetzt werden. Allerdings gibt es hier etwas andere Anforderungen, wobei es u.a. eine Rolle spielt, ob der Block wahrscheinlich wieder gebraucht wird der Block für die Konsistenz des Dateisystems wichtig ist der Block auf einem entfernbaren Datenträger liegt. 26

27 4. Leistungsoptimierung Die Ersetzungsstrategien kommen daher nur in abgewandter Form zum Einsatz. Dazu zählt auch die Technik einen Block bei passender Gelegenheit schon in den Cache zu bringen, bevor er benötigt wird. Wie bei Daten, die für die Konsistenz des DS wichtig sind, ist besondere Vorsicht bei Caching von Daten auf entfernbaren Datenträgern geboten: Wird der Datenträger entfernt, bevor Veränderungen mit dem Cache synchronisiert wurden, droht Datenverlust! Es gibt i.w. 2 Arten dem vorzubeugen: Bei Write-Through Caching geht man auf Nummer sicher: Caching wird im Prinzip nur für lesenden Zugriff gemacht. Jeder schreibende Zugriff hingegen findet nicht nur im Cache sondern auch im Speichermedium selbst statt. Der Cache kann mit Hilfe eines Systemaufrufs (sync) aktiv (oder regelmäßig) vor dem Entfernen abgeglichen werden. 27

28 4. Leistungsoptimierung 4.2 Geräte-spezifische Optimierungen Bei einer Festplatte lassen sich die Anzahl der Bewegungen des Plattenarms lässt sich verringern, wenn sich Blöcke, auf die wahrscheinlich sequentiell zugegriffen wird, nahe beieinander liegen. Dazu kann das BS versuchen, Dateien immer möglichst zusammenhängend abzulegen. Oft wird dies schon über die Firmware der Festplatte bzw. den Geräte-Treiber gemacht ( Geräteverwaltung). Ähnliches gilt in abwandelter Form auch für andere Formen von Permanentspeicher, wie Solid Stated Drives. Dies spielt also auf Ebene des Dateisystems keine Rolle. 28

29 4. Leistungsoptimierung 4.3 Nutzdatenverwaltung m Rahmen dieses Kapitels wurden eine Reihe von Problemen präsentiert, bei denen eine große Menge von (organisierten) Daten verwaltet werden muss, d.h. es werden Operationen zum Einfügen, Suchen und Entfernen benötigt Dies ist eine wohl-bekannte Problemstellung aus der Informatik. Dabei werden die o.g. Operationen Dictionary-Funktionen genannt. Beispiele im Kontext von Dateisystemen sind: Verwaltung des Cache: Ist ein Block im Cache (und wo)? Verwaltung von großen Verzeichnissen: Suche nach einer Datei Wahlfreier Zugriff (via FAT): In welchem Block ist das i-te Byte? Ohne besondere Vorkehrungen (d.h. sequentieller Zugriff) haben die Operationen i.a. einen sehr hohen Aufwand. Eine effiziente Alternative ist Hashing. 29

30 4. Leistungsoptimierung Dabei werden Daten an einem wohldefinierten Ort (Hash-Adresse) abgelegt und wieder gefunden, was durch die Benutzung einer Hash-Funktion geschieht. T 0 k6 k10 k9 k1 k2 k8 X h(k3) 1 X k7 h(k4) k3 X h(k2) = h(k5) k4 X k5 h(k1) m 1 X Problematisch ist dabei immer eine möglichst gleichmäßige Streuung der Daten. 30

31 4. Leistungsoptimierung Eine weitere Möglichkeit, die DictionaryFunktionen zu implementieren, bieten Balancierte Suchbäume (Balanced Binary Trees B-Trees). Sie wurden beim ReiserFS eingesetzt für die Organisation von Verzeichnissen, um die Suche von Dateien zu unterstützen. 31

32 4. Leistungsoptimierung Vorteile Die B-Trees ermöglichen (wie Hashing) eine höhere Zugriffsleistung und somit Durchsatz der Festplatte, da im Durchschnitt im Baum weniger Suchschritte von Nöten sind als in der Liste. z.b. ein Verzeichnis besitzt 1000 Einträge, dann werden bis zu 1000 Suchschritte in der verketteten Liste gebraucht, beim ausbalancierten binären Suchbaum jedoch nur 10 (log2 1000). Nachteile Nach jedem neuen Eintrag (Einfügen oder Löschen) in den Baum muss dieser neu `ausbalanciert` werden. Das erfordert ggf. einen höhere Rechenleistung als bei anderen Verfahren. Die Implementierung der 'Ausbalancierung' resultiert in einem komplexerem Programmcode, der ca. 5x größer ist als bei ext2fs. Besonders das Ausbalancieren ist ein komplizierter Vorgang. Somit steigt natürlich auch die Fehleranfälligkeit. 32

33 5. Konsitenz von Datei-Systemen Dateisysteme sind aus komplexen Zusammenhängen aufgebaut und für jede Veränderung sind eine ganze Reihe von Aktionen notwendig, bis die Veränderung fertig gestellt ist. Falls es während einer solchen Veränderung zu einem Systemabsturz, einem ungesicherten Stromausfall o.ä. kommt, können die anfallenden Arbeiten nicht mehr korrekt ausführen (Inkonsistenzen). 5.1 File-System Check Seit dem Anfang der Unix-Dateisysteme gibt es ein Programm, das die Systeme überprüft und gegebenenfalls repariert - file system check (fsck). In der Regel werden die Dateisysteme beim Systemstart geprüft, bevor sie gemountet sind (und dadurch von Prozessen benutzt und verändert werden). Auch für eine manuelle Anwendung von fsck wird in den meisten Fällen das Dateisystem abgehängt und erst dann überprüft. 33

34 5. Konsitenz von Datei-Systemen Hörsaal-Übung: Nachfolgend sind verschiedene Ergebnisse eines fsckdurchlaufs angegeben. Dabei wurde für jeden Block protokolliert, wie oft er in einer Datei und wie oft er in der Freiliste vorkommt. Stellen Sie fest, welche Zustände konsistent sind und wie mit inkonsistenten Zuständen verfahren werden soll! 34

35 5. Konsitenz von Datei-Systemen Gleichzeitig zur Konsistenz-Prüfung auf Basis von Blöcken können die Verzeichnisse überprüft werden, indem protokolliert wird in wie vielen Ordnern eine Datei verzeichnet ist (a). Dies kann dann mit dem Wert des I-Nodes verglichen werden, der Hard-Links implementiert (b): Gilt a=b, ist alles in Ordnung Gilt a>b, wird b=a gesetzt, um zu gewährleisten, dass die Datei beim letzten Löschen auch wirklich von der Platte entfernt wird. Im Fall a<b könnte es zum vorzeitigen Entfernen von der Platte kommen, obwohl noch Verweise auf die Datei bestehen (Datenverlust). Daher wird ebenfalls b=a gesetzt. Darüber hinaus existiert eine recht lange Liste erlaubter aber dennoch sonderbarer Situationen, die die Ausgabe einer Warnung wert sind (z.b. Zugriffsrecht 0007) 35

36 5. Konsitenz von Datei-Systemen 5.2 Die Überprüfung beim Systemstart Jedes Mal, wenn das System neu gebootet wird, werden alle Dateisysteme überprüft. In der Regel wird aber nur überprüft, ob sie "sauber" sind - nur wenn nicht, wird die eigentliche Überprüfung gestartet. Dazu wird im Superblock ein so genanntes Valid-Flag (Clean-Flag) benutzt: Jedes Mal, wenn ein Dateisystem gemountet wird, wird dieses Flag auf 0 gesetzt. Erst beim ordentlichen Abhängen durch umount wird es wieder auf 1 gesetzt. Falls das System nicht sauber heruntergefahren wird, wird das Flag also nicht gesetzt. Beim Systemstart überprüft das fsck-programm also zunächst, ob dieses Flag auf 1 steht: Falls ja, so gilt das Dateisystem als sauber und es wird nicht überprüft. Falls nein, wird eine Überprüfung durchgeführt. Zusätzlich enthält der Superblock einen Zähler, der beschreibt, wie oft das Dateisystem gemountet wurde, seit es das letzte Mal überprüft wurde. Nach 20 erfolgten Mounts wird überprüft, auch wenn das Flag gesetzt ist. 36

37 5. Konsitenz von Datei-Systemen 5.3 Journaling Die Überprüfung auf Konsistenz bei großen Platten hat einen hohen Zeitaufwand, da jede Datei auf der Partition getestet werden muss, ob sie fehlerhaft ist. Abhilfe schafft ein so genanntes Journaling Filesystem: Jede Operation auf dem Dateisystem wird als Transaktion (z.b. das Kopieren einer Datei) aufgefasst und in einem Journal notiert, bevor sie ausgeführt wird (d.h. Protokollierung der Veränderung von Metadaten den Verwaltungsdaten des DS) Ein solche Transaktion besteht dabei immer aus mehreren Einzelschritten (z.b. Anlegen der Datei im Zielverzeichnis, Lesen der Daten, Schreiben der Daten). Sollte einer dieser Schritte durch einen Systemabsturz unterbrochen werden, wären das DS nicht mehr konsistent. Erst wenn die Transaktion vollständig abgearbeitet ist, wird dieser Eintrag aus dem Journal wieder entfernt, denn dann ist das DS wieder konsistent. 37

38 5. Konsitenz von Datei-Systemen Somit ist im Journal immer notiert welche Dateien momentan in Bearbeitung stehen. Somit gilt nach einem Ausfall: Es müssen nur die Dateien überprüft werden, die im Journal erwähnt sind. Auf Grund der Einträge im Journal lässt sich feststellen, wann in etwa die Unterbrechung einer Transaktion stattgefunden hat. So ist es z.b. möglich bei einem unvollendetem Schreibvorgang die Daten auf den Ausgangszustand zurück zu setzen (Recovery der nicht geschlossenen Transaktionen). Im Wesentlichen gibt hierbei zwei verschiedene Betriebssarten: Metadaten-Journaling: Nur die Änderungen der Metadaten werden festgehalten zur Konsistenz des Datensystems (d.h. beste Performance aber geringste Datensicherheit) (Full-)Journaling: auch die Veränderungen an Nutzerdaten werden im Journal gespeichert zur Konsistenz der Datei-Inhalte (langsam, aber sehr sicher). 38

39 8. Linux Dateisysteme Linux unterstützt nicht ein bestimmtes Dateisystem, sondern erlaubt durch eine einheitliche Schnittstelle zum Linux-Kern (dem Virtual Filesystem Switch, VFS oder einfach virtuelles Filessystem genannt), mehrere Dateisysteme transparent zu verwenden. Der VFS stellt einen definierten Übergang zwischen Betriebssystemkern und den unterschiedlichen Dateisystemen dar. Insgesamt ergeben sich folgende Schichten des Dateisystems: Prozess 1 Prozess 2... Prozess n Nutzermodus Systemmodus VFS ext2 msdos... jfs proc Dateisystem Puffercache... 39

40 8. Linux Dateisysteme Auf Ebene der Programmierung greift ein Nutzerprozess immer über Systemaufrufe des VFS auf ein physisches Dateisystem zu. Systemaufrufe zum Datei-Management (z.b. read() und write()) sind dabei VFS-Funktionen. Nutzermodus: Der Anwendungsprogrammierer muss also Details einzelner Dateisystem nicht kennen, z.b wie der Cache-Mechanismus funktioniert. Der Programmierer braucht (und soll) nicht einmal wissen, auf welchem Dateisystem (-typ) die Dateien, die später mit dem Programm kopiert werden, physisch sind. Systemmodus: Ein Kernel-Programmierer hingegen muss die interne Struktur (C-Datenstruktur und die C-Funktionen zu ihrer Manipulation) vom VFS oder des Dateisystems kennen. Soll z.b. das VFS bei Aufruf eines Anwendungsprogramms, das read() die Anzahl der gelesenen Bytes in einer Protokolldatei speichern, muss ein Kernel-Programmierer die VFS read-funktionen ändern. Soll diese Protokollierung lediglich beim ext2 Dateisystem vollzogen werden, muss ein Kernel-Programmierer die interne Struktur des ext2 System kennen und den read-aufruf ändern. 40

41 8. Linux Dateisysteme Das VFS ist selbst wie ein I-Node-basiertes Dateisystem strukturiert: So ist z.b. ein Verzeichnis lediglich eine Datei, die andere Dateien enthält. Falls ein unterstütztes Dateisysteme dagegen einen anderen Mechanismus verwendet, muss die Implementierung eine Datei für jedes Verzeichnis automatisch erzeugen. Der Linux-Kernel braucht nicht für jede read()-funktion jedes Dateisystems einen Systemaufruf haben. Wird ein eigenes Dateisystem entworfen, muss die vorgegeben Programmier-Schnittstelle des VFS bedient werden, d.h. es müssen Funktionen bereit gestellt werden wie z.b. int int int int int int (*unlink) (struct inode *,const char *,int); (*symlink) (struct inode *,const char *,int,const char *); (*mkdir) (struct inode *,const char *,int,int); (*lseek) (struct inode *, struct file *, off_t, int); (*read) (struct inode *, struct file *, char *, int); (*write) (struct inode *, struct file *, const char *, int); 41