Filesystems எப்படி வேலை செய்கின்றன: inodes, journaling, மற்றும் page cache?

Question

IT Interview Practice · Accepted Answer

ஒரு **filesystem** ஒரு தட்டையான disk blocks வரிசையை files மற்றும் directories-இன் ஒரு படிநிலையாக மாற்றி, அதை நம்பகமானதாகவும் வேகமானதாகவும் ஆக்க metadata மற்றும் free space-ஐ நிர்வகிக்கிறது.

## Inodes: ஒரு file என்பது metadata + block pointers

UNIX filesystems-இல், ஒவ்வொரு file-ம் ஒரு **inode** (index node) — file-இன் **metadata** (size, owner, permissions, timestamps, link count) மற்றும் **அதன் data blocks-க்கான pointers**-ஐ வைத்திருக்கும் ஒரு structure. Inode எதைச் சேமிக்க*வில்லை* என்பதைக் கவனிக்கவும்: **filename**. பெயர்கள் **directories**-இல் வாழ்கின்றன, அவை பெயர் → inode number-ஐ map செய்யும் files மட்டுமே:

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

இதனால்தான் ஒரு **hard link** என்பது அதே inode-ஐச் சுட்டும் இரண்டாவது directory entry மட்டுமே (link count 2), மேலும் `rm` உண்மையில் `unlink` — அது ஒரு பெயரை நீக்கி, link count பூஜ்ஜியத்தை அடையும்போது மட்டுமே inode-ஐ விடுவிக்கிறது.

## Journaling: crashes-ஐத் தாண்டி உயிர்பிழைத்தல்

ஒரு single logical operation (உ.ம். ஒரு append) பல blocks-ஐத் தொடுகிறது — inode, free-space bitmap, data. நடுவில் ஒரு crash filesystem-ஐ inconsistent ஆக விடுகிறது. ஒரு **journal** முதலில் நோக்கிய மாற்றங்களை ஒரு log-க்கு எழுதி, பிறகு அவற்றைப் பயன்படுத்துகிறது; ஒரு crash-க்குப் பிறகு FS ஒரு மெதுவான முழு scan (`fsck`)-க்குப் பதிலாக journal-ஐ replay செய்கிறது (அல்லது discard செய்கிறது). Modes பாதுகாப்பை வேகத்திற்காக trade செய்கின்றன: **metadata மட்டும்** journal (வேகமான, பொதுவான) vs metadata **மற்றும் data**.

## Page cache & I/O paths

Kernel file data-ஐ RAM-இல் **page cache**-இல் cache செய்கிறது, எனவே re-reads memory-ஐ அடைந்து, writes **buffered** ஆகி பின்னர் flush ஆகின்றன (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 வேகமானது, ஆனால் "எழுதப்பட்ட" data `fsync` வரை durable அல்ல; databases பெரும்பாலும் caching மற்றும் durability-ஐ துல்லியமாகக் கட்டுப்படுத்த **direct I/O** மற்றும் தங்கள் சொந்த buffer pool-ஐப் பயன்படுத்துகின்றன.

## இது ஏன் முக்கியம்

Filesystem internals அன்றாட நடத்தையை விளக்குகின்றன: hard links ஏன் வேலை செய்கின்றன, ஒரு process இன்னும் திறந்து வைத்திருக்கும் ஒரு file-ஐ நீக்குவது அது மூடும்வரை ஏன் space-ஐ விடுவிக்காது, durability-க்கு `fsync` ஏன் அத்தியாவசியம் (மற்றும் தவிர்க்கப்படும்போது ஒரு உன்னதமான data-loss bug), மற்றும் ஒரு file-இன் இரண்டாவது read ஏன் உடனடியானது (page cache). Senior engineers ஒரு database-க்கு buffered vs direct I/O தேர்ந்தெடுக்கும்போது, cache-க்கு RAM அளவிடும்போது, அல்லது ஒரு crash-consistency சிக்கலை debug செய்யும்போது இவற்றைப் பற்றி சிந்திக்கிறார்கள்.

Inodes: ஒரு file என்பது metadata + block pointers

Journaling: crashes-ஐத் தாண்டி உயிர்பிழைத்தல்

Page cache & I/O paths

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்