Jak fungují souborové systémy: inody, journaling a page cache?

Question

IT Interview Practice · Accepted Answer

**Souborový systém (filesystem)** mění ploché pole diskových bloků na hierarchii souborů a adresářů a spravuje metadata a volné místo tak, aby to bylo spolehlivé a rychlé.

## Inody: soubor je metadata + ukazatele na bloky

V UNIXových souborových systémech je každý soubor **inode** (index node) — struktura držící **metadata** souboru (velikost, vlastník, oprávnění, časové značky, počet odkazů) a **ukazatele na jeho datové bloky**. Všimněte si, co inode *neukládá*: **název souboru**. Názvy žijí v **adresářích**, což jsou jen soubory mapující název → číslo inodu:

```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)──▶ ...
                                 └──────────────┘
```

Proto je **hard link** jen druhý adresářový záznam ukazující na tentýž inode (link count 2) a proč `rm` je vlastně `unlink` — odstraní název a inode uvolní teprve tehdy, když počet odkazů klesne na nulu.

## Journaling: přežití pádů

Jediná logická operace (např. append) sáhne na několik bloků — inode, bitmapu volného místa, data. Pád uprostřed zanechá souborový systém nekonzistentní. **Journal** nejprve zapíše zamýšlené změny do logu a pak je aplikuje; po pádu FS journal přehraje (nebo zahodí) místo pomalého úplného skenu (`fsck`). Režimy vyměňují bezpečnost za rychlost: journalovat **jen metadata** (rychlé, běžné) versus metadata **i data**.

## Page cache a cesty I/O

Kernel cachuje data souborů v RAM v **page cache**, takže opakovaná čtení zasáhnou paměť a zápisy jsou **bufferované** a vyprázdněné později (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)
```

Bufferované I/O je rychlé, ale „zapsaná“ data nejsou trvanlivá (durable), dokud nepřijde `fsync`; databáze často používají **direct I/O** plus vlastní buffer pool, aby přesně řídily cachování a trvanlivost.

## Proč je to důležité

Vnitřnosti souborového systému vysvětlují každodenní chování: proč fungují hard linky, proč smazání souboru, který má proces stále otevřený, neuvolní místo, dokud jej nezavře, proč je `fsync` nezbytný pro trvanlivost (a klasický bug se ztrátou dat, když se vynechá) a proč je druhé čtení souboru okamžité (page cache). Senior inženýři o tom uvažují při volbě bufferovaného vs direct I/O pro databázi, dimenzování RAM pro cache nebo ladění problému konzistence po pádu.

Inody: soubor je metadata + ukazatele na bloky

Journaling: přežití pádů

Page cache a cesty I/O

Proč je to důležité

Související otázky