Inode ও Filesystem গঠন — যেখানে ফাইলের নাম-ই থাকে না

(ক) ls /data/-এ big.log আর থাকবে না। rm = unlink(), যা directory-র data block থেকে “big.log” নামের entry সরিয়ে দেয় সাথে সাথেই — এটা synchronous, তাই unlink() ফেরত আসার মুহূর্তেই কোনো readdir()/ls আর এই নামটা দেখবে না।

(খ) হ্যাঁ, সম্পূর্ণ স্বাভাবিকভাবে পড়তে/লিখতে পারবে। কারণটা এই লেসনের দুইটা counter মনে করুন — inode-এর i_links_count আর আগের লেসনের struct file-এর f_count। unlink() শুধু i_links_count-কে 1 → 0 করেছে। প্রোগ্রামটার fd-র সাথে যুক্ত struct file এখনো inode-কে reference করছে (f_count \>= 1), তাই কার্নেল inode আর তার data block মুক্ত করে না।

(গ) inode আর ব্লক ফ্রি হবে ঠিক তখন যখন প্রোগ্রামটা close(fd) ডাকবে (বা প্রোগ্রামটা ক্র্যাশ করে/শেষ হয়ে যায়, যাতে কার্নেল তার সব fd বন্ধ করে দেয়)। শর্ত: i_links_count == 0 এবং কোনো খোলা reference নেই — দুইটাই মিলতে হবে। close()-এর মুহূর্তে যদি এটাই শেষ reference হয়, কার্নেল তখন block bitmap আর inode bitmap-এ bit ক্লিয়ার করে জায়গাটা সত্যিকারভাবে মুক্ত ঘোষণা করে।

একটা প্র্যাক্টিক্যাল পরিণতি: যতক্ষণ প্রোগ্রামটা fd খোলা রাখে, df ডিস্ক ব্যবহার কমতে দেখাবে না, যদিও ls/du (path দিয়ে) ফাইলটা আর দেখতেই পাবে না — realworld সেকশনের “df ভরা, du খালি” ঘটনার ঠিক এই প্রক্রিয়া। এই আচরণটা এতটাই দরকারি যে অনেক প্রোগ্রাম ইচ্ছাকৃতভাবে ব্যবহার করে: একটা temp ফাইল খুলেই সাথে সাথে unlink() করা — ফাইলটা তখন কোনো namespace-এ দৃশ্যমান না, শুধু সেই একটা process-এর fd দিয়ে অ্যাক্সেসযোগ্য, আর process শেষ হলে স্বয়ংক্রিয়ভাবে পরিষ্কার (O_TMPFILE ফ্ল্যাগ, Linux 3.11+, ঠিক এই প্যাটার্নটাকে একধাপে করে দেয়)।

Level 9-এর সাথে যোগ: distributed filesystem-এ (NFS) এই একই সেমান্টিক্স রাখা কঠিন — client যদি একটা ফাইল খোলা রাখা অবস্থায় অন্য client সেটা unlink করে, server-কে “silly rename” (.nfsXXXXXXXX নামে গোপনে rename) করতে হয় local unlink সেমান্টিক্স নকল করতে, কারণ NFS protocol-এ “deleted কিন্তু খোলা” ধারণাটা native না।

(ক) Pointers per block:

$\frac{1024 \text{ বাইট}}{4 \text{ বাইট/pointer}} = 256 \text{ pointer}$

(খ) Direct + single indirect:

(গ) Double indirect যোগ করে:

Double indirect একটা ব্লক যার প্রতিটা entry একটা single-indirect block-এর ঠিকানা, আর প্রতিটা single-indirect আবার ২৫৬টা data block ধরে:

$\text{double indirect ব্লক সংখ্যা} = 256 \times 256 = 65{,}536$ $\text{double indirect বাইট} = 65{,}536 \times 1024 = 67{,}108{,}864 \text{ বাইট} \approx 64\text{MB}$

সর্বমোট:

$10{,}240 + 262{,}144 + 67{,}108{,}864 = 67{,}381{,}248 \text{ বাইট} \approx 64.26\text{MB}$

লক্ষ করুন এই লেসনের “example” সেকশনের ৪KB ব্লক/১০২৪ pointer-per-block হিসাবের সাথে তুলনা করলে — এখানে ব্লক ছোট (১KB) আর pointer-per-block কম (২৫৬, কারণ ১০২৪÷৪) হওয়ায় প্রতিটা স্তরের multiplier ছোট, ফলে triple indirect ছাড়াই (শুধু double পর্যন্ত) সর্বোচ্চ সাইজ মাত্র ~৬৪MB-তে থেমে যায় — যেখানে ৪KB ব্লকে শুধু double indirect-ই ৪GB কভার করত। এই প্যাটার্নটাই মূল শিক্ষা: block size দ্বিগুণ করলে pointers-per-block দ্বিগুণ হয়, আর প্রতিটা indirection স্তরে সেই গুণিতক নিজের সাথে গুণ হয় — তাই ছোট block size দিয়ে design করা একটা filesystem বড় ফাইলের জন্য অনেক বেশি indirection-স্তর “খরচ” করে, একই কারণে পুরনো filesystem ছোট block size-এ ছোট max-file-size সীমায় আটকা পড়ত।

Level 6-এর সাথে যোগ: এই “প্রতি স্তরে গুণিতক” প্যাটার্নটা ঠিক B-tree-এর branching factor বনাম উচ্চতার সম্পর্কের মতোই — Level 6-এর algorithms module-এ B-tree analysis করার সময় এই একই গণিত ফিরে আসবে, আর দেখবেন কেন ডাটাবেস index-এ branching factor বড় রাখা (disk-block-সাইজ align করে) height কমিয়ে I/O কমায়।

du -h এখন দেখাবে 1.0M (বা কাছাকাছি, filesystem-এর নিজস্ব ছোট metadata overhead-সহ কিছুটা বেশি) — 4.0K না, যদিও লেখা ডেটা নিজে সব শূন্য বাইট।

এখানে একটা সূক্ষ্ম কিন্তু গুরুত্বপূর্ণ পয়েন্ট: truncate -s 1G কোনো ব্লক বরাদ্দ করেনি বলে hole (zero পড়া হয় ব্লক ছাড়াই)। কিন্তু dd ... conv=notrunc একটা সাধারণ write() syscall, যেটা কার্নেলের কাছে “এই রেঞ্জে এই বাইটগুলো লেখো” — কার্নেল ডেটা পরীক্ষা করে “এগুলো তো সব শূন্য, তাই hole-ই রেখে দিই” এই optimization সাধারণত করে না (ext4 ডিফল্টে করে না; কিছু filesystem/ফাইল-সিস্টেম-নির্দিষ্ট hole-punching থাকতে পারে কিন্তু সেটা explicit fallocate(FALLOC_FL_PUNCH_HOLE) ছাড়া ঘটে না)। ফলে প্রথম ১MB-এর জন্য প্রকৃত data block বরাদ্দ হয়ে যায়, বিষয়বস্তু জিরো হলেও।

ls -l sparse.img এখনো 1.0G-ই দেখাবে, একবিন্দুও না বদলে — কারণ i_size নির্ধারিত হয় ফাইলের সর্বোচ্চ পৌঁছানো offset দিয়ে (আগের লেসনের একই নিয়ম), আর truncate -s 1G সেটা আগেই 1GB বসিয়ে দিয়েছে। ১MB লেখা সেই সীমার অনেক ভেতরে, তাই i_size অপরিবর্তিত।

সংক্ষেপে: i_size (ls -l) বলে “ফাইল কতদূর পর্যন্ত বিস্তৃত বলে দাবি করে”, i_blocks/du বলে “প্রকৃতপক্ষে কতটা ডিস্ক দখল করে আছে” — আর এই দুইটা সংখ্যা independent, একটা আরেকটা থেকে অনুমান করা যায় না।

একটা সত্যিকার hole বানাতে চাইলে dd-এর বদলে fallocate --punch-hole --offset 0 --length 1M sparse.img লাগবে, অথবা প্রথম থেকেই সেই রেঞ্জে কখনো না লেখা — কারণ hole তৈরি হয় “কখনো লেখা হয়নি” থেকে, “শূন্য লেখা হয়েছে” থেকে না।

Level 12-এর সাথে যোগ: cloud storage billing (AWS EBS, GCP Persistent Disk) ঠিক i_blocks-ভিত্তিক allocation গণনা করে, i_size না — তাই একটা “provisioned 1TB” volume-এ মাত্র ১০GB প্রকৃত ডেটা থাকলে thin-provisioning-এ বিল হয় ~১০GB-র, পুরো ১TB-র না। Level 12-এ এই thin-provisioning মডেল বিস্তারিত আসবে।

হ্যাঁ, edit-টা সবগুলো hard-linked কপিকেই বদলে দেবে — /data/today/report.pdf সহ, আর প্রতিটা backup তারিখেও যদি সেই তারিখে ফাইলটা অপরিবর্তিত থেকে থাকে (cp -al-এ hard link হয়েছিল)।

কারণ: cp -al করে প্রতিটা ফাইলের একটা নতুন directory entry বানায় যা একই inode-কে নির্দেশ করে (এই লেসনের প্রথম section-এর link() ঠিক এটাই)। report.pdf-এর একটাই inode, একটাই data block সেট — শুধু directory entry-র সংখ্যা বেড়েছে (i_links_count অনেকগুলো তারিখ জুড়ে বাড়তে থাকবে)।

vim-এর edit কীভাবে সমস্যা করে তা নির্ভর করে vim কীভাবে সেভ করে:

ডিফল্ট vim আচরণে সমস্যা হতো না, কিন্তু এটা backup design হিসেবে বিপজ্জনকভাবে ভঙ্গুর — কোনো টুল যদি in-place write করে (অনেক প্রোগ্রাম করে, বিশেষত database বা লগ ফাইলে append), পুরো backup history নীরবে করাপ্ট হয়ে যায়, আর কেউ বুঝতেও পারবে না যতক্ষণ না পুরনো backup restore করে দেখছে।

সমাধান — backup-কে সত্যিই read-only করে দিন filesystem-স্তরে:

# প্রতিটা backup snapshot তৈরির পরে
chmod -R a-w /backup/2026-08-18
# আরো কড়া: immutable attribute (ext4-এ), root-ও override করতে chattr লাগবে
sudo chattr -R +i /backup/2026-08-18

chattr +i (immutable flag, i_flags-এ EXT4_IMMUTABLE_FL) সেট করলে সেই inode-এ কোনো write, rename, এমনকি delete-ও কার্নেল-স্তরে ব্লক হয়ে যায় — vim-এর in-place write ব্যর্থ হবে EPERM দিয়ে, চুপচাপ করাপ্ট হবে না। এটা chmod-এর চেয়ে শক্তিশালী কারণ chmod ownership/permission দিয়ে আটকায় (root বাইপাস করতে পারে), chattr +i filesystem-level সুরক্ষা।

Level 8-এর সাথে যোগ: এই পুরো সমস্যাটা — “shared underlying storage, কিন্তু logically independent copy” — copy-on-write-এর মূল ধারণা, যেটা পরের লেসনের শেষে btrfs/ZFS আলোচনায় আসবে, আর Level 8-এর database module-এ MVCC (multi-version concurrency control)-এও একই প্যাটার্ন ফিরে আসে: একটা row-এর একাধিক “version” শেয়ার্ড স্টোরেজে থাকে যতক্ষণ না কেউ সত্যিই একটা version বদলায়, তখন নতুন version আলাদা হয়ে যায় — hard-link backup আর MVCC দুটোই “শেয়ার করো যতক্ষণ বদলাচ্ছ না, বদলালে আলাদা করো” নীতির প্রয়োগ, যদিও hard link-এ সেই বিচ্ছেদটা automatic না (এখানেই এই প্রশ্নের বিপত্তি)।

এই workload-এর দুইটা বিপরীতমুখী চাপ: লক্ষ লক্ষ ছোট ফাইল মানে প্রতি-inode metadata overhead সবচেয়ে গুরুত্বপূর্ণ (ছোট ফাইলে addressing metadata-র আকার inode-এর নিজের আকারের একটা বড় অংশ হয়ে যেতে পারে), আর মাঝে মাঝে বড় ফাইল মানে সেই বড় ফাইলগুলোর জন্য compact large-range addressing দরকার।

বিকল্প (ক) — খাঁটি direct+indirect: ছোট ফাইলের জন্য (২KB, ৪KB ব্লকে ১ ব্লকই যথেষ্ট) এটা চমৎকার — একটা মাত্র direct pointer, কোনো indirect ব্লক ছোঁয়ারই দরকার নেই, ন্যূনতম metadata। কিন্তু বড় (কয়েক GB) attachment ফাইলে ভয়াবহ — এই লেসনের example-এর হিসাব অনুযায়ী একটা contiguous ১GB ফাইলেও শত শত indirect block পয়েন্টার লাগবে, প্রতিটা pointer আলাদা যদি allocator perfectly contiguous জায়গা নাও দেয় (fragmentation সাধারণ)। এই workload-এর জন্য বড়-ফাইল-দিকটায় দুর্বল।

বিকল্প (খ) — pure extent-based: বড় ফাইলে চমৎকার (এই লেসনের ~১০০KB বনাম ~১২ বাইট তুলনা)। কিন্তু ছোট ফাইলে অতিরিক্ত জটিলতা — একটা extent struct (ee_block, ee_len, ee_start) একটা single direct pointer-এর চেয়ে ভারী (১২ বাইট বনাম ৪ বাইট), যখন ফাইলটা এমনিতেই এক ব্লকের — extent-এর “রেঞ্জ বর্ণনা করার” শক্তিটাই এখানে অপচয়, কারণ length সবসময় ১। লক্ষ লক্ষ এমন ফাইলে এই ছোট overhead গুণিতক হয়ে যোগ হয়।

বিকল্প (গ) — hybrid, সুপারিশকৃত: এটাই ext4 প্রকৃতপক্ষে করে, আর এই workload-এর জন্য সবচেয়ে যুক্তিসঙ্গত। inode-এর ভেতরে ছোট সংখ্যক (ext4-এ ৪টা) extent সরাসরি রাখা — একটা ২KB ফাইলে একটামাত্র extent (ee_block=0, ee_len=1) লাগে, যেটা inode-এর ভেতরেই বসে যায়, কোনো অতিরিক্ত ব্লক ছোঁয়া লাগে না (extent সামান্য বড় হলেও, এখনো “১ ব্লক-ই যথেষ্ট” শ্রেণির কর্মক্ষমতা)। বড় ফাইলে যখন extent সংখ্যা ৪ ছাড়িয়ে যায়, তখনই একটা B-tree-এ ছড়িয়ে পড়ে (extent tree) — কিন্তু এই খরচ শুধু সেই সংখ্যালঘু বড় ফাইলেই লাগে, লক্ষ লক্ষ ছোট ফাইলের কেউ এই খরচ বহন করে না।

অতিরিক্ত ডিজাইন বিবেচনা এই নির্দিষ্ট workload-এর জন্য:

• inline data — কিছু আধুনিক filesystem (ext4-এর inline_data ফিচার, btrfs) খুবই ছোট ফাইল (কয়েকশ বাইট, একটা ছোট ইমেইল header তো এই রেঞ্জে পড়তেই পারে) সরাসরি inode-এর ভেতরে রেখে দেয়, কোনো আলাদা data block ছাড়াই — একটা data block বরাদ্দ (৪KB, ফাইল ২০০ বাইট হলেও পুরো ব্লক দখল) সম্পূর্ণ এড়িয়ে যায়। এই workload-এ (mail) ছোট email-এর একটা অংশ সহজেই এই সীমার নিচে পড়বে।
• inode density — mkfs-এর সময় inode-প্রতি-বাইট অনুপাত টিউন করা জরুরি (mkfs.ext4 -i); লক্ষ লক্ষ ছোট ফাইলের workload-এ ডিফল্ট অনুপাতে inode ফুরিয়ে যেতে পারে যদিও ডিস্ক স্পেস বাকি থাকে (ENOSPC “No space left on device” আসলেও কারণ inode শেষ, ব্লক না) — df -i দিয়ে এটা আলাদা করে দেখা যায় সাধারণ df-এর থেকে।
• directory scaling — লক্ষ লক্ষ ছোট ফাইল একই directory-তে রাখলে linear directory ফরম্যাট ধ্বসে পড়ে; এখানে hashed B-tree directory (HTree/H-tree) বাধ্যতামূলক, ঐচ্ছিক না।

Level 6-এর সাথে যোগ: এই hybrid-এর নকশা নীতিটাই — “সাধারণ কেসে ছোট/দ্রুত, বিরল কেসে scalable, দুটোর মধ্যে একটা threshold-ভিত্তিক switch” — ঠিক small-vector-optimization বা adaptive data structure-এর (যেমন Redis-এর ziplist বনাম full hash table, ছোট collection-এ compact encoding, বড় হলে সুইচ) একই সাধারণ প্যাটার্ন, যা Level 6-এর algorithms module-এ amortized/adaptive data structure আলোচনায় আরো গভীরভাবে আসবে।