Nachdem wir uns jetzt einige Dateisysteme konkret angeschaut haben und dabei natürlich auch ein

Stück weit über die Funktionalität und auch die Komplexität der Funktionsweise von Dateisystemen

eine ganze Menge kennengelernt haben, möchte ich jetzt auf ein ganz wesentliches Thema noch

eingehen, das gerade sich aus dieser Komplexität der Verwaltungsstrukturen und der Abläufe in so

einem Dateisystem ergibt, nämlich was passiert, wenn Fehler passieren, wenn diese Datenstrukturen,

die benötigt werden, um so ein Dateisystem zu verwalten, in irgendeiner Weise inkonsistent werden.

Das Stichwort hierzu ist Dateisysteme mit Fehlererholung beziehungsweise mit

Fehlererholungskonzepten. Das zentrale Problem ist, dass die Metadaten und die aktuell genutzten

Datenblöcke von geöffneten Dateien aus Effizienzgründen im Hauptspeicher gehalten

werden. Das heißt, im Hauptspeicher wird eine Art Cache für die Daten auf dem Hintergrundspeicher

angelegt und verwaltet. Das hat natürlich zur Folge, dass der Zugriff erheblich effizienter ist.

Wir hatten ja, als ich das Thema Harddisks besprochen habe, bereits kennengelernt, wie

viel langsamer eine Harddisk ist im Vergleich zu einem Hauptspeicherzugriff. Also wir reden da

ja vom Faktor Millionen oder mehrere Millionen. Und selbst bei einer SSD haben wir immer noch

ein Faktor 1000 im Vergleich zu der Akten Hauptspeicher zugegriffen in der Geschwindigkeit,

sodass es natürlich unmittelbar einleuchtend ist, dass es wichtig ist, Daten, die gerade aktuell

im Anwendungsprogramm benötigt werden vom Hintergrundspeicher, erst mal im Hauptspeicher

zwischenzuspeichern und die Operationen dort durchzuführen und das auch nicht ständig

zurückzuschreiben, sondern dann eben solche Daten erst dann zurückzuschreiben, wenn die

Operationen auch fertig sind. Aber die Konsistenz zwischen dem Cache und der Platte muss natürlich

regelmäßig hergestellt werden und dafür gibt es zwei Ansätze. Das sind eine synchrone Änderungen.

Da kehrt eine Operation, typischerweise dann Systemaufruf, erst dann zurück, wenn die Änderungen

auf der Platte gespeichert wurden. Dann kann man also auch im Anwendungsprogramm sicher sein, wenn

dieser Befehl, also der Systemaufruf wie White beispielsweise oder wenn man Direktory anlegt,

mkdir oder wenn man Datei anlegt und create, wenn also dieser Systemaufruf zurückkommt im

Anwendungsprogramm, dann ist die Operation tatsächlich auch persistent auf der Platte gespeichert.

Bei Asynchronänderungen dagegen erfolgen die Änderungen nur im Cache, im Hauptspeicher und

die Operation kehrt dann auch sofort zurück. Das ist natürlich dann erheblich schneller und die

Synchronisation mit der Platte erfolgt einfach später, asynchron zum weiteren Ablauf des

Anwendungsprogramms. In Bezug auf die Geschwindigkeit ist das natürlich von großem Vorteil. In Bezug

auf die Stabilität, im Fehlerfall kann das natürlich ein echtes Problem sein und Fehlerursachen

können ganz banal sein, wie ein Stromausfall oder noch schlimmer, ein dummer Benutzer schaltet

einfach den Rechner aus oder auch einfach ein Systemabsturz aufgrund eines Softwarefehlers im

Betriebssystem. Ja und wenn so ein Problem auftaucht, so eine Fehlerursache auftaucht,

dann sind die Auswirkungen aufs Dateisystem eventuell fatal. Cache-Inhalte und aktuelle

eine Ausgabeoperation gehen verloren und das kann dazu führen, dass Metadaten und auch Dateinhalte

dazu inkonsistent werden. Also Beispiele wären, dass ein Katalog-Eintrag zu einer Datei fehlt oder

auch umgekehrt, dass es einen Katalog-Eintrag gibt, aber die Datei dazu existiert überhaupt nicht.

Oder ein ganz, ganz fataler Fehler ist, dass ein Block in einer Datei bereits benutzt wird,

aber er ist noch in der Liste der freien Blöcke als frei markiert. Und wenn man mit so einem System

dann weiterarbeitet, würde dieser Block ja möglicherweise dann auch, wenn für eine andere

Datei ein freier Block benötigt wird, wieder hergenommen und dann habe ich den gleichen Datenblock

in zwei Dateien eingehängt und das hat natürlich ganz verheerende Folgen. Das merkt man erstmal

direkt gar nicht, aber ich ändere an der einen Datei was und dann ändert sich irgendwo in der

anderen Datei, wo eben dieser Block auch drin steckt, eben auch etwas und dann ist die kaputt

und umgekehrt natürlich dann genauso. Sowas muss man natürlich erkennen können und dann auch

reparieren und dafür gibt es auch Reparaturprogramme wie Checkdisk oder Scandisk oder Fallsystemcheck,

je nach Betriebssystem. Die überprüfen letztendlich die ganzen Metadaten, die Zusammenhänge und auch

die freien Blöcke und überprüfen das beispielsweise ein Block, der als frei markiert ist, eben nicht auch

gleichzeitig in einem Inode oder im Fall von NTFS in der Masterfile Table in so einem Eintrag