Dosya sistemleri nasıl çalışır: inode'lar, journaling ve page cache?

Question

IT Interview Practice · Accepted Answer

Bir **dosya sistemi (filesystem)**, düz bir disk blokları dizisini dosya ve dizinlerden oluşan bir hiyerarşiye dönüştürür; bunu güvenilir ve hızlı kılmak için metadata'yı ve boş alanı yönetir.

## Inode'lar: bir dosya = metadata + blok pointer'ları

UNIX dosya sistemlerinde her dosya bir **inode**'dur (index node) — dosyanın **metadata**'sını (boyut, sahip, izinler, zaman damgaları, link sayısı) ve **veri bloklarına pointer'ları** tutan bir yapı. Bir inode'un ne saklamadığına dikkat edin: **dosya adı**. Adlar **dizinlerde** yaşar; dizinler ise yalnızca ad → inode numarası eşlemesi yapan dosyalardır:

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

İşte bu yüzden bir **hard link**, yalnızca aynı inode'a işaret eden ikinci bir dizin girdisidir (link count 2) ve `rm` aslında `unlink`'tir — bir adı kaldırır ve inode'u yalnızca link count sıfıra ulaştığında serbest bırakır.

## Journaling: çökmelerden sağ çıkmak

Tek bir mantıksal işlem (ör. bir append) birkaç bloğa dokunur — inode, boş alan bitmap'i, veri. Yarı yolda bir çökme dosya sistemini tutarsız bırakır. Bir **journal** önce amaçlanan değişiklikleri bir log'a yazar, sonra uygular; bir çökmeden sonra dosya sistemi, yavaş bir tam tarama (`fsck`) yerine journal'ı yeniden oynatır (replay) ya da atar. Modlar güvenliği hıza karşı takas eder: **yalnızca metadata** journal'lama (hızlı, yaygın) ile metadata **ve veri** journal'lama.

## Page cache & I/O yolları

Kernel, dosya verisini RAM'de **page cache**'te önbelleğe alır, böylece yeniden okumalar belleğe isabet eder ve yazmalar **tamponlanır (buffered)** ve daha sonra flush edilir (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 hızlıdır, ama "yazılmış" veri `fsync`'e kadar kalıcı (durable) değildir; veritabanları önbellekleme ve kalıcılığı hassas biçimde kontrol etmek için genellikle **direct I/O** ve kendi buffer pool'larını kullanır.

## Neden önemli

Dosya sistemi iç yapıları gündelik davranışı açıklar: hard link'lerin neden çalıştığı, bir process'in hâlâ açık tuttuğu bir dosyayı silmenin o kapanana dek neden alan boşaltmadığı, `fsync`'in kalıcılık için neden temel olduğu (ve atlandığında klasik bir veri kaybı bug'ı olduğu) ve bir dosyanın ikinci okumasının neden anında olduğu (page cache). Senior mühendisler bir veritabanı için buffered vs direct I/O seçerken, cache için RAM boyutlandırırken ya da bir crash-consistency sorununu debug ederken bunlar üzerine akıl yürütür.

Inode'lar: bir dosya = metadata + blok pointer'ları

Journaling: çökmelerden sağ çıkmak

Page cache & I/O yolları

Neden önemli

İlgili sorular