एक filesystem disk blocks की एक सपाट array को files और directories के एक पदानुक्रम में बदलता है, और metadata व free space का प्रबंधन करता है ताकि वह विश्वसनीय और तेज़ हो।
UNIX filesystems में, हर file एक (index node) है — एक संरचना जो file का (आकार, owner, permissions, timestamps, link count) और उसके रखती है। ध्यान दें कि एक inode क्या रखता: । नाम में रहते हैं, जो केवल नाम → inode number को map करने वाली files हैं:
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 को केवल तभी free करता है जब link count शून्य पर पहुँच जाए।
एक अकेला logical operation (उदा. एक append) कई blocks को छूता है — inode, free-space bitmap, data। बीच में एक crash filesystem को असंगत छोड़ देता है। एक journal पहले इच्छित बदलावों को एक log में लिखता है, फिर उन्हें लागू करता है; crash के बाद FS एक धीमे पूर्ण scan (fsck) के बजाय journal को replay (या discard) करता है। Modes सुरक्षा को गति से बदलते हैं: केवल metadata journal करना (तेज़, आम) बनाम metadata और data दोनों।
Kernel file data को RAM में page cache में cache करता है, इसलिए re-reads memory में hit होते हैं और writes buffered होकर बाद में flush होते हैं (write-back):
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 का आंतरिक कार्य रोज़मर्रा के व्यवहार की व्याख्या करता है: hard links क्यों काम करते हैं, ऐसी file जिसे कोई process अभी भी खुली रखे हुए है, उसे delete करने पर बंद होने तक जगह क्यों free नहीं होती, fsync durability के लिए क्यों आवश्यक है (और छूट जाने पर एक classic data-loss bug), और किसी file का दूसरा read तुरंत क्यों होता है (page cache)। Senior engineers एक database के लिए buffered बनाम direct I/O चुनते समय, cache के लिए RAM का आकार तय करते समय, या एक crash-consistency समस्या को debug करते समय इनके बारे में तर्क करते हैं।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें