Filesystemలు ఎలా పనిచేస్తాయి: inodes, journaling, మరియు page cache?

Question

IT Interview Practice · Accepted Answer

ఒక **filesystem** disk blocksల చదునైన అర్రేను files మరియు directoriesల సోపానక్రమంగా మారుస్తుంది, దాన్ని నమ్మదగినదిగా, వేగవంతంగా చేయడానికి metadata మరియు ఖాళీ స్థలాన్ని నిర్వహిస్తుంది.

## Inodes: ఒక file అంటే metadata + block pointers

UNIX filesystemలలో, ప్రతి file ఒక **inode** (index node) — 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ను (link count 2) సూచించే రెండవ directory entry మాత్రమే, మరియు `rm` నిజానికి `unlink` — అది ఒక పేరును తొలగిస్తుంది, link count సున్నాకు చేరినప్పుడు మాత్రమే inodeను విడుదల చేస్తుంది.

## Journaling: crashల నుండి బయటపడటం

ఒక తార్కిక ఆపరేషన్ (ఉదా. ఒక append) అనేక blocksను తాకుతుంది — inode, free-space bitmap, data. మధ్యలో ఒక crash filesystemను అస్థిరంగా వదిలేస్తుంది. ఒక **journal** ముందుగా ఉద్దేశించిన మార్పులను ఒక logకు వ్రాస్తుంది, తర్వాత వాటిని వర్తింపజేస్తుంది; crash తర్వాత FS నెమ్మది పూర్తి scan (`fsck`) బదులు journalను replay (లేదా discard) చేస్తుంది. మోడ్‌లు safetyను speed కోసం ట్రేడ్ చేస్తాయి: **metadata మాత్రమే** journal (వేగం, సాధారణం) vs metadata **మరియు data**.

## Page cache & I/O paths

Kernel file డేటాను RAMలో **page cache**లో cache చేస్తుంది, కాబట్టి తిరిగి-చదవడాలు memoryను తాకుతాయి, వ్రాతలు **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 కాదు; databaseలు తరచుగా cachingను, durabilityను కచ్చితంగా నియంత్రించడానికి **direct I/O** మరియు వాటి స్వంత buffer poolను వాడతాయి.

## ఇది ఎందుకు ముఖ్యం

Filesystem అంతర్గత విషయాలు రోజువారీ ప్రవర్తనను వివరిస్తాయి: hard links ఎందుకు పనిచేస్తాయి, ఒక ప్రాసెస్ ఇంకా తెరిచి ఉంచిన fileను తొలగించడం అది మూసివేసే వరకు స్థలాన్ని ఎందుకు విడుదల చేయదు, durability కోసం `fsync` ఎందుకు అవసరం (దాన్ని విస్మరించినప్పుడు ఒక క్లాసిక్ డేటా-నష్ట బగ్), మరియు ఒక file యొక్క రెండవ చదవడం ఎందుకు తక్షణం (page cache). Senior ఇంజనీర్‌లు ఒక databaseకు buffered vs direct I/O ఎంచుకునేటప్పుడు, cache కోసం RAMను sizing చేసేటప్పుడు, లేదా crash-consistency సమస్యను debug చేసేటప్పుడు వీటి గురించి తర్కిస్తారు.

Inodes: ఒక file అంటే metadata + block pointers

Journaling: crashల నుండి బయటపడటం

Page cache & I/O paths

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు