Hogyan működnek a fájlrendszerek: inode-ok, journaling és a page cache?

Question

IT Interview Practice · Accepted Answer

Egy **fájlrendszer** a lemezblokkok lapos tömbjét fájlok és könyvtárak hierarchiájává alakítja, kezelve a metaadatokat és a szabad helyet, hogy ez megbízható és gyors legyen.

## Inode-ok: egy fájl = metaadat + blokk-pointerek

A UNIX fájlrendszerekben minden fájl egy **inode** (index node) — egy struktúra, amely a fájl **metaadatait** (méret, tulajdonos, jogosultságok, időbélyegek, link count) és **az adatblokkjaira mutató pointereket** tartalmazza. Figyeld meg, mit *nem* tárol az inode: a **fájlnevet**. A nevek a **könyvtárakban** élnek, amelyek csak név → inode-szám leképezést tároló fájlok:

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

Ezért egy **hard link** csak egy második könyvtárbejegyzés, amely ugyanarra az inode-ra mutat (link count 2), és ezért az `rm` valójában `unlink` — eltávolít egy nevet, és csak akkor szabadítja fel az inode-ot, amikor a link count nullára csökken.

## Journaling: túlélni a crasheket

Egyetlen logikai művelet (pl. egy append) több blokkot érint — az inode-ot, a szabad hely bitmapjét, az adatot. Egy félúton bekövetkező crash inkonzisztensen hagyja a fájlrendszert. Egy **journal** először egy logba írja a szándékolt változtatásokat, majd alkalmazza őket; crash után a fájlrendszer visszajátssza (vagy eldobja) a journalt egy lassú teljes vizsgálat (`fsck`) helyett. A módok biztonságot cserélnek sebességre: journal **csak a metaadatokról** (gyors, gyakori) vagy a metaadatokról **és az adatokról** is.

## Page cache és I/O-utak

A kernel a fájladatokat a RAM-ban, a **page cache**-ben tárolja, így az újraolvasások a memóriát találják el, az írások pedig **pufferelve** vannak, és később kerülnek kiírásra (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)
```

A buffered I/O gyors, de a "kiírt" adat nem tartós `fsync`-ig; az adatbázisok gyakran **direct I/O**-t plusz saját buffer poolt használnak a cache-elés és a tartósság pontos vezérlésére.

## Miért fontos

A fájlrendszer belső működése magyarázza a mindennapi viselkedést: miért működnek a hard linkek, miért nem szabadul fel a hely egy olyan fájl törlésekor, amelyet egy process még nyitva tart, amíg be nem zárja, miért elengedhetetlen az `fsync` a tartóssághoz (és miért klasszikus adatvesztési bug, ha kihagyják), és miért azonnali egy fájl második olvasása (page cache). A senior mérnökök ezekről gondolkodnak, amikor buffered vs direct I/O között választanak egy adatbázishoz, RAM-ot méreteznek a cache-hez, vagy egy crash-konzisztencia-problémát debuggolnak.

Inode-ok: egy fájl = metaadat + blokk-pointerek

Journaling: túlélni a crasheket

Page cache és I/O-utak

Miért fontos

Kapcsolódó kérdések