Cum funcționează filesystem-urile: inode-uri, journaling și page cache?

Question

IT Interview Practice · Accepted Answer

Un **filesystem** transformă un array plat de blocuri de disc într-o ierarhie de fișiere și directoare, gestionând metadatele și spațiul liber pentru ca asta să fie fiabilă și rapidă.

## Inode-uri: un fișier este metadate + pointeri către blocuri

În filesystem-urile UNIX, fiecare fișier este un **inode** (index node) — o structură care conține **metadatele** fișierului (dimensiune, proprietar, permisiuni, timestamp-uri, link count) și **pointeri către blocurile sale de date**. Observă ce *nu* stochează un inode: **numele fișierului**. Numele stau în **directoare**, care sunt doar fișiere ce mapează nume → număr de inode:

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

De aceea un **hard link** este doar o a doua intrare de director care pointează spre același inode (link count 2) și de ce `rm` este de fapt `unlink` — elimină un nume și eliberează inode-ul doar când link count-ul ajunge la zero.

## Journaling: supraviețuirea crash-urilor

O singură operație logică (ex. un append) atinge mai multe blocuri — inode-ul, bitmap-ul de spațiu liber, datele. Un crash la mijloc lasă filesystem-ul inconsistent. Un **journal** scrie mai întâi modificările intenționate într-un log, apoi le aplică; după un crash, FS-ul reia (replay) sau aruncă journal-ul în loc de o scanare completă lentă (`fsck`). Modurile schimbă siguranță pe viteză: journal **doar de metadate** (rapid, comun) față de metadate **și date**.

## Page cache și căile de I/O

Kernel-ul face cache datelor de fișier în RAM în **page cache**, așa că recitirile ating memoria, iar scrierile sunt **buffered** și golite mai târziu (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 este rapid, dar datele „scrise" nu sunt durabile până la `fsync`; bazele de date folosesc adesea **direct I/O** plus propriul buffer pool pentru a controla precis cache-ul și durabilitatea.

## De ce contează

Interiorul filesystem-ului explică comportamente de zi cu zi: de ce funcționează hard link-urile, de ce ștergerea unui fișier pe care un proces încă îl ține deschis nu eliberează spațiu până când acesta se închide, de ce `fsync` este esențial pentru durabilitate (și un bug clasic de pierdere de date când e omis) și de ce a doua citire a unui fișier este instantanee (page cache). Inginerii senior raționează despre acestea când aleg buffered vs direct I/O pentru o bază de date, dimensionează RAM-ul pentru cache sau depanează o problemă de consistență la crash.

Inode-uri: un fișier este metadate + pointeri către blocuri

Journaling: supraviețuirea crash-urilor

Page cache și căile de I/O

De ce contează

Întrebări conexe