Dateisysteme und Persistenz

Von Blöcken zu Dateien

Ein Dateisystem verwaltet im Kern drei Dinge. Am Beispiel der Unix-Familie, also Linux und macOS – Windows mit NTFS funktioniert im Prinzip ähnlich:

Dass Name und Datei getrennt sind, hat überraschende Folgen. Eine Datei kann mehrere Namen haben – das sind Hardlinks. Und Löschen entfernt zunächst nur einen Namen. Probier es aus:

Zwei Dinge aus dem Experiment sind in der Praxis wichtig:

• Gelöscht heißt nicht weg. Die Blöcke gelten als frei, ihr Inhalt bleibt, bis sie neu beschrieben werden. Darauf beruhen Wiederherstellungsprogramme – und deshalb muss man Datenträger vor dem Verkauf sicher löschen. Bei SSDs sorgt der TRIM-Befehl allerdings dafür, dass freigegebene Blöcke bald tatsächlich gelöscht werden.
• Fragmentierung. Wächst eine Datei und dahinter ist kein Platz, landen ihre Blöcke verstreut. Auf Festplatten mit mechanischem Lesekopf war das teuer, daher das Defragmentieren. Auf SSDs spielt es kaum eine Rolle.

Das eigentliche Problem: der Stromausfall

Hängt man an eine Datei einen Block an, müssen drei Dinge auf die Platte: der Datenblock selbst, der aktualisierte Inode (neue Größe, neuer Blockverweis) und die Bitmap (Block jetzt belegt). Das sind drei Schreibvorgänge an drei Stellen – und die Platte kann immer nur einen nach dem anderen garantieren. Was passiert, wenn dazwischen der Strom ausfällt?

Früher half nach einem Absturz nur eines: fsck oder chkdsk prüfte beim Neustart das ganze Dateisystem auf Widersprüche. Bei großen Platten dauerte das Stunden. Die beiden modernen Verfahren machen das überflüssig:

Wer genau hinschaut, erkennt das Muster: Ein Journal ist dasselbe wie das Write-Ahead-Log einer Datenbank, und das Umhängen eines Zeigers ist eine atomare Operation. Dateisysteme und Datenbanken lösen hier dasselbe Problem.

„Gespeichert“ ist nicht gespeichert: fsync

Wie im Eintrag Betriebssystem beschrieben, kehrt ein Schreibaufruf zurück, sobald der Kernel die Daten in seinem Zwischenspeicher im RAM hat. Auf die Platte schreibt er sie später, gebündelt und in günstiger Reihenfolge. Das ist schnell – aber bei einem Stromausfall sind die letzten Sekunden weg. Und selbst die SSD hat noch einen eigenen Zwischenspeicher.

Wer eine Garantie braucht, ruft fsync auf: Der Aufruf kehrt erst zurück, wenn die Daten dauerhaft gespeichert sind. Datenbanken tun das bei jedem Commit – das ist einer der Gründe, warum ein Commit messbar Zeit kostet.

Eine Datei sicher ersetzen

Eine Konfigurationsdatei direkt zu überschreiben, ist gefährlich: Stürzt das Programm mittendrin ab, ist sie halb alt, halb neu. Das bewährte Muster: in eine temporäre Datei schreiben, erzwingen, dann umbenennen. Ein Umbenennen innerhalb desselben Dateisystems ist atomar – danach sieht jeder entweder die alte oder die neue Datei, nie eine halbe.

Path ziel = Path.of("config.json");
Path tmp  = ziel.resolveSibling("config.json.tmp");

try (FileChannel ch = FileChannel.open(tmp, CREATE, WRITE, TRUNCATE_EXISTING)) {
    ch.write(ByteBuffer.wrap(daten));
    ch.force(true);                                 // fsync: Daten und Metadaten auf die Platte
}
Files.move(tmp, ziel, StandardCopyOption.ATOMIC_MOVE);  // alt oder neu – nie halb

Ganz gründlich wäre es, danach auch das Verzeichnis zu synchronisieren, damit der neue Name selbst einen Absturz übersteht. Das geht in Java nur plattformabhängig; für die meisten Anwendungen genügt das Muster oben.

Was SSDs anders machen

Eine SSD kann einen Block nicht einfach überschreiben. Flash-Speicher lässt sich nur in großen Einheiten löschen, und jede Zelle verträgt nur eine begrenzte Zahl von Löschvorgängen. Ein Controller in der SSD, die Flash Translation Layer, schreibt deshalb jede Änderung an eine neue Stelle, führt Buch, wo welcher Block gerade wirklich liegt, verteilt die Abnutzung gleichmäßig und räumt im Hintergrund auf. Die SSD betreibt also intern selbst so etwas wie Copy-on-Write – unter einem Dateisystem, das davon nichts weiß.

Die gängigen Dateisysteme

In der Cloud kommt eine weitere Art hinzu: Objektspeicher wie Amazon S3. Er sieht aus wie ein Dateisystem, ist aber keines – es gibt kein Umbenennen, kein Anhängen und keine echten Ordner, nur Schlüssel und unveränderliche Objekte. Wer dort Dateisystem-Gewohnheiten voraussetzt, erlebt Überraschungen.

Für Entwickler übersetzt

Häufige Irrtümer

Verwandte Begriffe