एउटा filesystem ले disk block हरूको समतल array लाई file र directory को पदानुक्रममा परिणत गर्छ, त्यसलाई भरपर्दो र छिटो बनाउन metadata र खाली ठाउँ व्यवस्थापन गर्दै।
UNIX filesystem हरूमा, प्रत्येक file एउटा (index node) हो — file को (size, owner, permission, timestamp, link count) र राख्ने एउटा संरचना। inode ले के त्यो नोट गर्नुहोस्: । नाम हरूमा बस्छन्, जुन केवल नाम → inode number map गर्ने file हरू हुन्:
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 मुक्त गर्छ।
एउटै तार्किक operation (जस्तै एउटा append) ले धेरै block छुन्छ — inode, free-space bitmap, र data। बीचमै crash हुँदा filesystem असङ्गत रहन्छ। एउटा journal ले पहिले अभिप्रेत परिवर्तनहरू एउटा log मा लेख्छ, अनि तिनलाई लागू गर्छ; crash पछि FS ले सुस्त full scan (fsck) को सट्टा journal लाई replay (वा discard) गर्छ। Mode हरूले सुरक्षा र गतिको साटासाट गर्छन्: metadata मात्र journal (छिटो, सामान्य) बनाम metadata र data।
Kernel ले file data लाई RAM मा page cache मा cache गर्छ, त्यसैले पुनः-पढाइले memory मा hit गर्छ र लेखाइहरू 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 नभएसम्म टिकाउ हुँदैन; database हरूले caching र durability लाई सटीक रूपमा नियन्त्रण गर्न प्रायः direct I/O र आफ्नै buffer pool प्रयोग गर्छन्।
Filesystem को भित्री कुराले दैनिक व्यवहार व्याख्या गर्छ: किन hard link काम गर्छ, किन कुनै process ले अझै खुला राखेको file मेट्दा यो बन्द नभएसम्म ठाउँ मुक्त हुँदैन, किन fsync durability का लागि आवश्यक छ (र छोड्दा एउटा उत्कृष्ट data-loss bug), र किन file को दोस्रो पढाइ तत्काल हुन्छ (page cache)। Senior engineer हरूले database का लागि buffered बनाम direct I/O छान्दा, cache का लागि RAM आकार निर्धारण गर्दा, वा crash-consistency समस्या debug गर्दा यी बारे तर्क गर्छन्।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्