Wie funktionieren Dateisysteme: Inodes, Journaling und der Page Cache?

Question

IT Interview Practice · Accepted Answer

Ein **Dateisystem (Filesystem)** verwandelt ein flaches Array von Disk-Blöcken in eine Hierarchie aus Dateien und Verzeichnissen und verwaltet die Metadaten und den freien Speicherplatz, damit das zuverlässig und schnell ist.

## Inodes: eine Datei ist Metadaten + Block-Pointer

In UNIX-Dateisystemen ist jede Datei ein **Inode** (Index Node) — eine Struktur, die die **Metadaten** der Datei (Größe, Owner, Berechtigungen, Timestamps, Link Count) und **Pointer auf ihre Datenblöcke** enthält. Beachte, was ein Inode *nicht* speichert: den **Dateinamen**. Namen liegen in **Verzeichnissen**, die einfach Dateien sind, die Name → Inode-Nummer abbilden:

```text
directory "docs"                  inode 1042              data blocks
┌───────────────────┐            ┌──────────────┐         ┌────────┐
│ "report.txt" →1042│───────────▶│ mode, uid    │──ptr───▶│ block  │
│ "notes.txt"  →1050│            │ size, times  │──ptr───▶│ block  │
└───────────────────┘            │ link count=2 │         └────────┘
                                 │ block ptrs   │──(indirect)──▶ ...
                                 └──────────────┘
```

Deshalb ist ein **Hard Link** einfach ein zweiter Verzeichniseintrag, der auf denselben Inode zeigt (Link Count 2), und deshalb ist `rm` in Wirklichkeit `unlink` — es entfernt einen Namen und gibt den Inode erst frei, wenn der Link Count null erreicht.

## Journaling: Abstürze überleben

Eine einzelne logische Operation (z. B. ein Append) berührt mehrere Blöcke — den Inode, die Free-Space-Bitmap, die Daten. Ein Absturz mittendrin hinterlässt das Dateisystem inkonsistent. Ein **Journal** schreibt die beabsichtigten Änderungen zuerst in ein Log und wendet sie dann an; nach einem Absturz spielt das FS das Journal erneut ab (replay) oder verwirft es, statt eines langsamen vollständigen Scans (`fsck`). Modi tauschen Sicherheit gegen Geschwindigkeit: **nur Metadaten** journalen (schnell, verbreitet) versus Metadaten **und Daten**.

## Page Cache & I/O-Pfade

Der Kernel cached Dateidaten im RAM im **Page Cache**, sodass Re-Reads den Speicher treffen und Writes **gepuffert** und später geflusht werden (Write-Back):

```text
buffered I/O (default): app ↔ page cache ↔ disk   → cached, async writeback, fast re-reads
direct I/O (O_DIRECT):  app ↔ disk                → bypass the cache; DBs manage their own
fsync():                force buffered data to durable storage (required for real durability)
```

Buffered I/O ist schnell, aber "geschriebene" Daten sind erst nach `fsync` dauerhaft; Datenbanken verwenden oft **Direct I/O** plus einen eigenen Buffer Pool, um Caching und Dauerhaftigkeit präzise zu kontrollieren.

## Warum es wichtig ist

Dateisystem-Interna erklären Alltagsverhalten: warum Hard Links funktionieren, warum das Löschen einer Datei, die ein Prozess noch offen hält, keinen Platz freigibt, bis er sie schließt, warum `fsync` für Dauerhaftigkeit essenziell ist (und ein klassischer Datenverlust-Bug, wenn ausgelassen) und warum das zweite Lesen einer Datei sofort erfolgt (Page Cache). Senior-Ingenieure denken darüber nach, wenn sie Buffered vs. Direct I/O für eine Datenbank wählen, RAM für den Cache dimensionieren oder ein Crash-Konsistenz-Problem debuggen.

Inodes: eine Datei ist Metadaten + Block-Pointer

Journaling: Abstürze überleben

Page Cache & I/O-Pfade

Warum es wichtig ist

Ähnliche Fragen