Jak działają systemy plików: inody, journaling i page cache?

Question

IT Interview Practice · Accepted Answer

**System plików (filesystem)** zamienia płaską tablicę bloków dysku w hierarchię plików i katalogów, zarządzając metadanymi i wolną przestrzenią, by było to niezawodne i szybkie.

## Inody: plik to metadane + wskaźniki bloków

W systemach plików UNIX każdy plik jest **inodem** (index node) — strukturą trzymającą **metadane** pliku (rozmiar, właściciel, uprawnienia, znaczniki czasu, liczba dowiązań) i **wskaźniki do jego bloków danych**. Zwróć uwagę na to, czego inode *nie* przechowuje: **nazwy pliku**. Nazwy żyją w **katalogach**, które są po prostu plikami mapującymi nazwa → numer 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)──▶ ...
                                 └──────────────┘
```

To dlatego **twarde dowiązanie (hard link)** jest po prostu drugim wpisem katalogu wskazującym na ten sam inode (link count = 2) i dlaczego `rm` to naprawdę `unlink` — usuwa nazwę i zwalnia inode dopiero, gdy link count spadnie do zera.

## Journaling: przetrwanie awarii

Pojedyncza operacja logiczna (np. dopisanie) dotyka kilku bloków — inode, bitmapy wolnej przestrzeni, danych. Awaria w połowie zostawia system plików w stanie niespójnym. **Journal** najpierw zapisuje zamierzone zmiany do logu, a potem je stosuje; po awarii system plików odtwarza (replay) lub odrzuca (discard) journal zamiast powolnego pełnego skanu (`fsck`). Tryby wymieniają bezpieczeństwo na szybkość: journaling **tylko metadanych** (szybki, popularny) kontra metadanych **i danych**.

## Page cache i ścieżki I/O

Kernel cache'uje dane plików w RAM w **page cache**, więc ponowne odczyty trafiają w pamięć, a zapisy są **buforowane** i opróżniane później (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)
```

Buforowane I/O jest szybkie, ale „zapisane" dane nie są trwałe (durable) do momentu `fsync`; bazy danych często używają **direct I/O** plus własnej puli buforów, by precyzyjnie kontrolować cache'owanie i trwałość.

## Dlaczego to ważne

Wnętrze systemu plików tłumaczy codzienne zachowania: dlaczego działają twarde dowiązania, dlaczego usunięcie pliku, który proces wciąż trzyma otwartym, nie zwalnia miejsca do jego zamknięcia, dlaczego `fsync` jest niezbędny dla trwałości (i klasyczny bug utraty danych, gdy go pominąć) i dlaczego drugi odczyt pliku jest natychmiastowy (page cache). Inżynierowie senior rozumują o tym, wybierając buforowane vs direct I/O dla bazy danych, dobierając RAM na cache czy debugując problem spójności po awarii (crash-consistency).

Inody: plik to metadane + wskaźniki bloków

Journaling: przetrwanie awarii

Page cache i ścieżki I/O

Dlaczego to ważne

Powiązane pytania