Si funksionojnë filesystems: inodes, journaling, dhe page cache?

Question

IT Interview Practice · Accepted Answer

Një **filesystem** e kthen një varg të sheshtë blloqesh disku në një hierarki file-sh dhe directory-sh, duke menaxhuar metadata-n dhe hapësirën e lirë për ta bërë atë të besueshme dhe të shpejtë.

## Inodes: një file është metadata + pointer-a blloqesh

Në filesystems UNIX, çdo file është një **inode** (index node) — një strukturë që mban **metadata**-n e file-t (madhësia, pronari, lejet, timestamps, link count) dhe **pointer-a te blloqet e tij të të dhënave**. Vër re çfarë një inode *nuk* e ruan: **emrin e file-t (filename)**. Emrat qëndrojnë në **directories**, të cilat janë thjesht file që paraqesin emër → numër 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)──▶ ...
                                 └──────────────┘
```

Kjo është arsyeja pse një **hard link** është thjesht një entry i dytë directory-je që tregon te i njëjti inode (link count 2), dhe pse `rm` në të vërtetë është `unlink` — heq një emër dhe e liron inode-n vetëm kur link count arrin në zero.

## Journaling: mbijetesa ndaj crash-eve

Një operacion i vetëm logjik (p.sh. një append) prek disa blloqe — inode-n, bitmap-in e hapësirës së lirë, të dhënat. Një crash në mes e lë filesystem-in jokoherent. Një **journal** së pari i shkruan ndryshimet e synuara në një log, pastaj i zbaton; pas një crash-i FS-ja e riluan (replay) (ose e hedh) journal-in në vend të një skanimi të plotë e të ngadaltë (`fsck`). Mënyrat shkëmbejnë sigurinë me shpejtësinë: journal **vetëm metadata** (i shpejtë, i zakonshëm) përballë metadata **dhe të dhënave**.

## Page cache & rrugët e I/O-së

Kernel-i i ruan në cache të dhënat e file-ve në RAM te **page cache**, kështu që rileximet prekin memorien dhe shkrimet **buffer-ohen** dhe flush-ohen më vonë (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 është i shpejtë, por të dhënat "e shkruara" nuk janë të qëndrueshme (durable) derisa `fsync`; bazat e të dhënave shpesh përdorin **direct I/O** plus buffer pool-in e tyre për të kontrolluar me saktësi caching-un dhe qëndrueshmërinë.

## Pse ka rëndësi

Brendësia e filesystem-it shpjegon sjelljen e përditshme: pse funksionojnë hard links, pse fshirja e një file që një process e mban ende të hapur nuk e liron hapësirën derisa ai të mbyllet, pse `fsync` është thelbësor për qëndrueshmërinë (dhe një bug klasik humbjeje të dhënash kur harrohet), dhe pse leximi i dytë i një file është i menjëhershëm (page cache). Inxhinierët senior arsyetojnë rreth këtyre kur zgjedhin buffered vs direct I/O për një bazë të dhënash, dimensionojnë RAM-in për cache, ose debug-ojnë një problem koherence pas crash-i.

Inodes: një file është metadata + pointer-a blloqesh

Journaling: mbijetesa ndaj crash-eve

Page cache & rrugët e I/O-së

Pse ka rëndësi

Pyetje të ngjashme