Kepiye filesystem mlaku: inode, journaling, lan page cache?

Question

IT Interview Practice · Accepted Answer

**Filesystem** ngowahi larik rata blok disk dadi hierarki file lan direktori, ngatur metadata lan ruang kosong supaya kuwi bisa dipercaya lan cepet.

## Inode: file iku metadata + pointer blok

Ing filesystem UNIX, saben file iku **inode** (index node) — struktur sing nyekel **metadata** file (ukuran, pemilik, ijin, timestamp, cacah link) lan **pointer menyang blok datane**. Gatekno apa sing *ora* disimpen inode: **jeneng file**. Jeneng manggon ing **direktori**, sing mung file sing ngepetakake jeneng → nomer 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)──▶ ...
                                 └──────────────┘
```

Iki sebabe **hard link** mung entri direktori kaping pindho sing nuduh menyang inode sing padha (link count 2), lan kenapa `rm` sabenere `unlink` — dheweke mbuwang jeneng lan mung mbebasake inode nalika link count tekan nol.

## Journaling: slamet saka crash

Siji operasi logis (contone append) nyenggol sawetara blok — inode, bitmap ruang kosong, data. Crash ing tengah dalan ninggalake filesystem ora konsisten. **Journal** dhisik nulis owah-owahan sing dikarepake menyang log, banjur nrapake; sawise crash, FS muter maneh (utawa mbuwang) journal tinimbang scan lengkap sing alon (`fsck`). Mode-mode nuker keamanan karo kacepetan: journal **mung metadata** (cepet, umum) lawan metadata **lan data**.

## Page cache & jalur I/O

Kernel nyimpen cache data file ing RAM ing **page cache**, mula maca ulang trep memori lan tulis di-**buffer** lan di-flush mengko (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 iku cepet, nanging data sing "wis ditulis" durung tahan (durable) nganti `fsync`; database kerep nganggo **direct I/O** ditambah buffer pool dhewe kanggo ngontrol caching lan daya tahan kanthi presisi.

## Kenapa iki penting

Njeron filesystem njlentrehake prilaku saben dina: kenapa hard link mlaku, kenapa mbusak file sing isih dibukak sawijining proses ora mbebasake ruang nganti ditutup, kenapa `fsync` penting kanggo daya tahan (lan bug ilang-data klasik nalika dilalekake), lan kenapa maca kaping pindho sawijining file iku sanalika (page cache). Insinyur senior menalar bab iki nalika milih buffered vs direct I/O kanggo database, ngukur RAM kanggo cache, utawa ndebug masalah konsistensi sawise crash.

Inode: file iku metadata + pointer blok

Journaling: slamet saka crash

Page cache & jalur I/O

Kenapa iki penting

Pitakon sing gegandhengan