Filesystems કેવી રીતે કામ કરે છે: inodes, journaling, અને page cache?

Question

IT Interview Practice · Accepted Answer

એક **filesystem** disk blocks ના flat array ને files અને directories ના પદાનુક્રમમાં ફેરવે છે, તેને વિશ્વસનીય અને ઝડપી બનાવવા metadata અને ખાલી જગ્યાનું સંચાલન કરે છે.

## Inodes: file એટલે metadata + block pointers

UNIX filesystems માં, દરેક file એક **inode** (index node) છે — એક structure જે file નું **metadata** (size, owner, permissions, timestamps, link count) અને **તેના data blocks ના pointers** રાખે છે. નોંધો કે inode શું *નથી* સંગ્રહતું: **filename**. નામો **directories** માં રહે છે, જે માત્ર name → inode number મૅપ કરતી 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 માંથી બચવું

એક જ logical operation (દા.ત. append) ઘણા blocks ને સ્પર્શે છે — inode, free-space bitmap, data. વચ્ચે crash filesystem ને inconsistent છોડી દે છે. એક **journal** પહેલા ધારેલા ફેરફારો log માં લખે છે, પછી તેમને લાગુ કરે છે; crash પછી FS ધીમા full scan (`fsck`) ને બદલે journal ને replay (કે discard) કરે છે. Modes safety ને speed સાથે trade કરે છે: journal **માત્ર metadata** (ઝડપી, સામાન્ય) સામે metadata **અને data**.

## Page cache અને I/O paths

Kernel file data ને RAM માં **page cache** માં cache કરે છે, તેથી re-reads memory ને hit કરે છે અને 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 ઝડપી છે, પણ "written" data `fsync` સુધી durable નથી; databases ઘણી વાર caching અને durability ને ચોક્કસ નિયંત્રિત કરવા **direct I/O** વત્તા પોતાનું buffer pool વાપરે છે.

## આ શા માટે મહત્વનું છે

Filesystem ના આંતરિક ભાગો રોજિંદા વર્તન સમજાવે છે: hard links શા માટે કામ કરે છે, process હજુ ખુલ્લી રાખેલી file ને delete કરવાથી તે બંધ થાય ત્યાં સુધી જગ્યા શા માટે મુક્ત થતી નથી, `fsync` durability માટે શા માટે આવશ્યક છે (અને છોડી દેવાય ત્યારે classic 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

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો