filesystems کیسے کام کرتے ہیں: inodes، journaling، اور page cache؟

Question

IT Interview Practice · Accepted Answer

ایک **filesystem** disk blocks کی ایک چپٹی صف کو files اور directories کے درجہ بندی میں بدل دیتا ہے، metadata اور خالی جگہ کو منظم کرتے ہوئے تاکہ یہ قابلِ اعتماد اور تیز ہو۔

## Inodes: ایک file metadata + block pointers ہے

UNIX filesystems میں، ہر file ایک **inode** (index node) ہے — ایک ساخت جو file کا **metadata** (سائز، مالک، اجازتیں، timestamps، link count) اور **اس کے data blocks کی طرف pointers** رکھتی ہے۔ غور کریں کہ inode کیا *نہیں* رکھتا: **filename**۔ نام **directories** میں رہتے ہیں، جو محض ایسی files ہیں جو نام → inode number میپ کرتی ہیں:

```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** محض ایک دوسری directory entry ہے جو اسی inode کی طرف اشارہ کرتی ہے (link count 2)، اور یہی وجہ ہے کہ `rm` دراصل `unlink` ہے — یہ ایک نام ہٹاتا ہے اور inode کو صرف تب آزاد کرتا ہے جب link count صفر پر پہنچے۔

## Journaling: کریشوں سے بچ نکلنا

ایک واحد منطقی آپریشن (مثلاً ایک append) کئی blocks کو چھوتا ہے — inode، خالی جگہ کا bitmap، ڈیٹا۔ بیچ میں ایک کریش filesystem کو غیر مستقل چھوڑ دیتا ہے۔ ایک **journal** پہلے مطلوبہ تبدیلیوں کو ایک log میں لکھتا ہے، پھر انہیں لاگو کرتا ہے؛ کریش کے بعد FS ایک سست مکمل اسکین (`fsck`) کے بجائے journal کو دوبارہ چلاتا (replay) ہے (یا رد کر دیتا ہے)۔ موڈز حفاظت کو رفتار کے بدلے تجارت کرتے ہیں: **صرف metadata** journal کرنا (تیز، عام) بمقابلہ metadata **اور data** دونوں۔

## Page cache اور I/O راستے

kernel file data کو RAM میں **page cache** میں cache کرتا ہے، اس لیے دوبارہ پڑھنے میموری سے ملتے ہیں اور لکھنے **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 تیز ہے، لیکن "لکھا ہوا" ڈیٹا `fsync` تک پائیدار (durable) نہیں ہوتا؛ databases اکثر **direct I/O** کے ساتھ اپنا buffer pool استعمال کرتے ہیں تاکہ caching اور durability کو باریک بینی سے کنٹرول کر سکیں۔

## یہ کیوں اہم ہے

Filesystem کے اندرونی معاملات روزمرہ رویے کی وضاحت کرتے ہیں: hard links کیوں کام کرتے ہیں، کسی ایسی file کو حذف کرنا جسے کوئی process ابھی بھی کھلا رکھے ہوئے ہے اس کے بند ہونے تک جگہ آزاد کیوں نہیں کرتا، `fsync` durability کے لیے کیوں ضروری ہے (اور چھوڑ دیے جانے پر ایک کلاسک data-loss bug)، اور کسی file کا دوسرا پڑھنا فوری کیوں ہوتا ہے (page cache)۔ Senior انجینئرز کسی database کے لیے buffered بمقابلہ direct I/O چنتے، cache کے لیے RAM کا سائز طے کرتے، یا کسی crash-consistency مسئلے کو ڈیبگ کرتے وقت ان کے بارے میں استدلال کرتے ہیں۔

Inodes: ایک file metadata + block pointers ہے

Journaling: کریشوں سے بچ نکلنا

Page cache اور I/O راستے

یہ کیوں اہم ہے

متعلقہ سوالات