Directory, link আর mounting — VFS

১ · Directory আসলে কী — নাম থেকে inode-এর একটি তালিকা

পর্ব ৪১-এ দেখেছেন একটি ফাইল খোলা, পড়া আর লেখা কীভাবে হয়। কিন্তু open("/home/rahim/notes.txt") লিখলে kernel ফাইলটি খুঁজে পায় কীভাবে? উত্তর হলো directory — যাকে Windows-এ সাধারণত “ফোল্ডার” বলা হয়। আর cd, ls, absolute আর relative path ব্যবহারের নিয়ম আপনি পর্ব ০৩-এ (Linux টার্মিনাল) শিখেছেন; এখানে আমরা দেখব পর্দার পেছনে কী ঘটে।

Unix-ধাঁচের file system-এ (ext4, XFS, APFS…) একটি ফাইলের সব তথ্য — মালিক, permission, আকার, সময়, ডেটা-ব্লকের ঠিকানা — থাকে তার inode-এ (inode-এর ভেতরের গঠন পর্ব ৪৩-এ)। Directory নিজেও একটি বিশেষ ধরনের ফাইল, যার ডেটা হলো কয়েকটি directory entry. ext4-এ প্রতিটি entry-তে থাকে inode নম্বর (৪ বাইট), entry-র দৈর্ঘ্য, নামের দৈর্ঘ্য, ফাইলের ধরন আর সর্বোচ্চ ২৫৫ বাইটের নাম। প্রতিটি directory-তে দুটি বিশেষ entry থাকে: . (নিজে) আর .. (মা-directory).

/home/rahim  (inode 2050)  — ডেটা-ব্লকে এই entry-গুলো:
  inode   type  name
  2050    dir   .
  131     dir   ..
  2101    dir   docs
  2207    file  notes.txt
  2300    link  latest

Directory-র ওপর ছয়টি মৌলিক কাজ

OS-এর বইগুলো সাধারণত directory-র ওপর এই কাজগুলোর কথা বলে। প্রতিটির পেছনে একটি বা দুটি system call আছে:

একটি খুঁটিনাটি: rmdir শুধু খালি directory মোছে (. আর .. ছাড়া কিছু না থাকলে)। rm -r আসলে user-space-এ ভেতরের সবকিছু একে একে unlink করে, শেষে rmdir. পুরো গাছ একবারে মোছার কোনো system call kernel-এ নেই।

২ · Directory-র পাঁচ রকম গঠন — single-level থেকে general graph

Directory কেমন আকৃতির হবে, তা নিয়ে OS-এর ইতিহাসে কয়েকটি ধাপ এসেছে। বিশ্ববিদ্যালয় আর চাকরির পরীক্ষায় এই পাঁচটির তুলনা প্রায়ই আসে।

Acyclic graph-এর তিনটি সমস্যা

• Aliasing: একই ফাইলের একাধিক নাম। du বা backup প্রোগ্রাম সাবধান না হলে একই ফাইল দুবার গুনবে বা দুবার কপি করবে।
• Dangling pointer: link যদি শুধু একটি path মনে রাখে (symlink), আর আসল ফাইল মুছে যায় — link এখন এমন কিছুকে দেখায় যা নেই। একে বলে dangling link. আরও খারাপ: পরে একই নামে অন্য কোনো ফাইল তৈরি হলে link চুপচাপ সেটিকে দেখাবে।
• মোছার হিসাব: একটি নাম মুছলে ফাইলটি কি সত্যিই মুছবে? সমাধান reference count: inode গোনে তাকে কতগুলো নাম দেখায় (link count). একটি নাম মুছলে গণনা এক কমে; শূন্য হলে (আর কোনো process ফাইলটি খোলা না রাখলে) তবেই ডেটা মুক্ত হয়। Unix এই পথই নিয়েছে — rm আসলে unlink, অর্থাৎ “একটি নাম সরানো”.

General graph: কেন reference count আর যথেষ্ট নয়

ধরুন /a/b একটি directory, আর তার ভেতরে loop নামে একটি hard link আছে যা আবার /a-কে দেখায়। এবার / থেকে a নামটি মুছে দিলেন। এখন a আর b একে অপরকে ধরে রেখেছে — দুজনের link count শূন্য নয়, অথচ মূল / থেকে কোনো পথে আর তাদের কাছে পৌঁছানো যায় না। Reference count দিয়ে এই জায়গা কখনো ফেরত আসবে না।

যুক্তিটি সাধারণভাবে বলা যায়: reference count একটি বস্তু মুক্ত করে তখনই, যখন তার দিকে আসা সব তীর চলে যায়। একটি cycle-এর প্রতিটি সদস্যের দিকে অন্তত একটি তীর cycle-এর ভেতর থেকেই আসে, তাই বাইরের সব নাম মুছলেও কোনো সদস্যের গণনা শূন্য হয় না। এমন জায়গা উদ্ধারের একমাত্র উপায় garbage collection: / থেকে পৌঁছানো যায় এমন সবকিছুতে দাগ দেওয়া (mark), তারপর দাগহীন সবকিছু মুক্ত করা (sweep). ডিস্কের লক্ষ লক্ষ inode-এ এটি চালানো অত্যন্ত ধীর। আরেকটি সমস্যা: cycle থাকলে ..-র মানে অস্পষ্ট — একাধিক মা থাকলে কোনটি?

৩ · Hard link আর symbolic link — একই ফাইলের দুই রকম দ্বিতীয় নাম

এখন আসল মজার অংশ। দুই রকম link-এর পার্থক্য বুঝলে আপনি backup, deployment, package manager আর container-এর অনেক রহস্য বুঝবেন।

নিচের ডায়াগ্রামে একটি ফাইল, তার একটি hard link আর একটি symlink — তারপর মোছা আর নতুন করে তৈরি। inode নম্বর কাল্পনিক; “পরে” চেপে প্রতিটি ঘর খেয়াল করুন।

এবার আসল Linux-এ একই পরীক্ষা। inode নম্বর প্রতি রানে আলাদা হবে, তাই script নম্বরের বদলে সম্পর্ক ছাপে — “একই inode” নাকি “আলাদা”. শেষে দুটি সীমাও দেখা যাবে: symlink-এর লুপ আর directory-র hard link.

rm -rf original.txt hard.txt soft.txt loopA loopB dir1 dirlink
echo "hi" > original.txt
ln original.txt hard.txt            # hard link: a second name for the same inode
ln -s original.txt soft.txt         # symlink: a tiny file that stores a path
ls -li --time-style=+%F original.txt hard.txt soft.txt
ino() { stat -c %i "$1"; }          # stat does not follow a symlink
[ "$(ino original.txt)" = "$(ino hard.txt)" ] && echo "hard.txt: SAME inode, link count $(stat -c %h hard.txt)"
[ "$(ino original.txt)" != "$(ino soft.txt)" ] && echo "soft.txt: OWN inode, stores '$(readlink soft.txt)' ($(stat -c %s soft.txt) bytes)"
echo "--- rm original.txt ---"
rm original.txt
echo "hard.txt: $(cat hard.txt) (link count now $(stat -c %h hard.txt))"
cat soft.txt 2>&1 || echo "soft.txt is dangling (cat exit $?)"
echo "--- create a NEW original.txt ---"
echo "new" > original.txt
echo "soft.txt: $(cat soft.txt)   hard.txt: $(cat hard.txt)"
echo "--- limits ---"
ln -s loopB loopA; ln -s loopA loopB
cat loopA 2>&1 || true
mkdir dir1; ln dir1 dirlink 2>&1 || true
echo "dir1 link count: $(stat -c %h dir1)"

4705992 -rw-r--r-- 2 wandbox wandbox  3 2026-10-25 hard.txt
4705992 -rw-r--r-- 2 wandbox wandbox  3 2026-10-25 original.txt
4705993 lrwxrwxrwx 1 wandbox wandbox 12 2026-10-25 soft.txt -> original.txt
hard.txt: SAME inode, link count 2
soft.txt: OWN inode, stores 'original.txt' (12 bytes)
--- rm original.txt ---
hard.txt: hi (link count now 1)
cat: soft.txt: No such file or directory
soft.txt is dangling (cat exit 1)
--- create a NEW original.txt ---
soft.txt: new   hard.txt: hi
--- limits ---
cat: loopA: Too many levels of symbolic links
ln: dir1: hard link not allowed for directory
dir1 link count: 2

নাম বদল, সরানো আর অন্য file system

একই file system-এর ভেতরে mv আসলে একটি rename() system call: পুরোনো entry সরিয়ে নতুন entry বসানো, inode আর ডেটা একটুও নড়ে না — তাই ২০ GB-র ভিডিও ফাইলও চোখের পলকে “সরে”. POSIX বলে rename() atomic: অন্য কেউ হয় পুরোনো নামটি দেখবেন, নয়তো নতুনটি — মাঝামাঝি কিছু নয়।

কিন্তু /home থেকে USB stick-এ (/media/usb) সরালে rename() EXDEV ফেরত দেয়, কারণ inode নম্বর অন্য file system-এ অর্থহীন। তখন mv নিজে থেকে পুরো ডেটা কপি করে, তারপর পুরোনোটি মোছে। ফলাফল: সময় লাগে, কাজটি আর atomic নয় (মাঝপথে বিদ্যুৎ গেলে দুই জায়গায় অর্ধেক থাকতে পারে), আর ফাইলের অন্য hard link-গুলোর সাথে সম্পর্ক ছিন্ন হয় — নতুন জায়গায় এটি এক-নামের নতুন ফাইল। Symlink কপি হয় symlink হিসেবেই, ভেতরের path না বদলে; relative path হলে নতুন জায়গায় ভেঙে যেতে পারে।

৪ · Windows আর macOS-এ link — shortcut, junction আর alias

“Windows-এ তো shortcut আছে, ওটাই কি symlink?” — না, আর পার্থক্যটা গুরুত্বপূর্ণ। Windows-এ চার রকম জিনিস আছে, আর এদের আচরণ সংস্করণ ও সেটিংসভেদে একটু বদলায়; নিচের সারাংশ সাধারণ ক্ষেত্রের জন্য:

একটি C প্রোগ্রাম CreateFile দিয়ে .lnk খুললে shortcut-এর লক্ষ্য নয়, ঐ .lnk ফাইলের বাইনারি ডেটাই পাবে — kernel এটিকে link বলে চেনে না। পরিচিত একটি junction-এর উদাহরণ: Vista থেকে পুরোনো প্রোগ্রামের সুবিধার জন্য C:\Documents and Settings একটি junction, যা C:\Users-কে দেখায়। macOS-এ symlink আর hard link দুই-ই আছে (BSD ঐতিহ্য), আর Finder-এর “alias” Windows shortcut-এর মতো একটি আলাদা ফাইল — তবে সেটি ফাইলের ভেতরের পরিচয়ও মনে রাখে, তাই লক্ষ্য সরালেও অনেক সময় খুঁজে পায়।

PS> cmd /c mklink /H copy2.txt notes.txt
Hardlink created for copy2.txt <<===>> notes.txt
PS> cmd /c mklink /J proj D:\work\project
Junction created for proj <<===>> D:\work\project
PS> fsutil hardlink list notes.txt
\Users\rahim\notes.txt
\Users\rahim\copy2.txt

৫ · Directory-র ভেতরের বাস্তবায়ন — linear list, hash table আর B-tree

একটি directory-তে নাম খোঁজার গতি নির্ভর করে entry-গুলো কীভাবে সাজানো তার ওপর। ছোট directory-তে কোনো পার্থক্য চোখে পড়ে না; কিন্তু একটি mail server বা ছবির সার্ভারে এক directory-তে লাখো ফাইল থাকতে পারে।

ext4-এর htree আসলে দুটির মিশ্রণ: নামের hash হিসাব করে, hash-কে চাবি ধরে একটি অগভীর B-tree-ধাঁচের index-এ খোঁজে, আর শেষ ধাপের leaf block-গুলো আগের মতোই সাধারণ linear entry. ফল: index-এর গভীরতা সাধারণত ১ বা ২ স্তর (বড় directory-র জন্য large_dir feature-এ ৩), তাই এক লাখ ফাইলেও কয়েকটি ব্লক পড়লেই নাম মেলে। একটি পার্শ্বফল: ext4-এ getdents64 entry দেয় hash-এর ক্রমে, তাই ls -f (না-সাজানো) এলোমেলো দেখায়; সাধারণ ls নিজেই নামগুলো সাজিয়ে দেখায়।

৬ · Path-name resolution — kernel কীভাবে একটি path খোঁজে

প্রতিটি open, stat, execve-এর শুরুতে kernel-কে একটি লেখা path থেকে একটি inode-এ পৌঁছাতে হয়। ক্লাসিক Unix-এ এই function-এর নাম ছিল namei (“name to inode”); Linux-এ কাজটি করে fs/namei.c-এর link_path_walk আর সঙ্গী function-গুলো। নিয়মগুলো:

1. Path / দিয়ে শুরু হলে খোঁজা শুরু process-এর root directory থেকে, নইলে তার cwd থেকে (দুটোই process-এর নিজস্ব, chroot আর container এ কারণেই কাজ করে)।
2. Path-কে / দিয়ে component-এ ভাঙা; একাধিক / একটি হিসেবে ধরা।
3. প্রতিটি মাঝের directory-তে execute (x) বা “search” permission লাগে; শুধু read (r) থাকলে নামের তালিকা দেখা যায়, কিন্তু ভেতরে ঢোকা যায় না (খুঁটিনাটি পর্ব ৪৭-এ)।
4. . মানে একই জায়গা, .. মানে মা-directory; root-এর .. root নিজেই।
5. কোনো component symlink হলে তার ভেতরের path পড়ে বাকি path-এর আগে বসিয়ে খোঁজা চলতে থাকে (শেষ component-এ অনুসরণ হবে কি না, তা system call আর flag-এর ওপর নির্ভর করে, যেমন lstat বা O_NOFOLLOW).
6. কোনো component একটি mount point হলে খোঁজা ঐ জায়গায় mount করা file system-এর root-এ লাফ দেয় (অংশ ৭)।

এত কাজ প্রতিবার ডিস্কে করলে কম্পিউটার অচল হতো। তাই Linux রাখে dentry cache: (মা-directory, নাম) → inode-এর একটি বড় hash table, RAM-এ। এমনকি “এই নামে কিছু নেই” ফলটিও মনে রাখা হয় (negative dentry) — PATH-এর প্রতিটি ফোল্ডারে একটি কমান্ড খোঁজার সময় এটি খুব কাজে লাগে।

এবার user-space থেকে একই কাজ নিজ হাতে: প্রোগ্রামটি দুটি directory আর একটি symlink বানায়, তারপর প্রতিটি component fstatat(…, AT_SYMLINK_NOFOLLOW) দিয়ে পরীক্ষা করে (এটিই lstat-এর আচরণ — symlink নিজেকে দেখায়), আর openat দিয়ে এক ধাপ এগোয়, ঠিক kernel-এর মতো এক directory থেকে পরেরটিতে।

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <unistd.h>

static ino_t walk(const char *path) {          /* resolve one component at a time */
    char buf[256], tgt[256];
    struct stat st;
    int n = 0, dfd = open(".", O_PATH | O_DIRECTORY);
    printf("walk %s\n", path);
    snprintf(buf, sizeof buf, "%s", path);
    for (char *c = strtok(buf, "/"); c; c = strtok(NULL, "/"), n++) {
        if (fstatat(dfd, c, &st, AT_SYMLINK_NOFOLLOW) != 0) { perror(c); return 0; }
        ssize_t k = readlinkat(dfd, c, tgt, sizeof tgt - 1);   /* -1 if not a symlink */
        tgt[k > 0 ? k : 0] = '\0';
        printf("  %d. %-6s %s%s\n", n + 1, c, S_ISLNK(st.st_mode) ? "symlink, follow -> " :
               S_ISDIR(st.st_mode) ? "directory" : "regular file", tgt);
        int next = openat(dfd, c, O_PATH);       /* O_PATH without O_NOFOLLOW follows links */
        close(dfd);
        dfd = next;
    }
    fstat(dfd, &st);
    close(dfd);
    printf("  components looked up: %d\n", n);
    return st.st_ino;
}

int main(void) {
    mkdir("d1", 0755); mkdir("d1/d2", 0755); unlink("lnk");
    close(open("d1/d2/f.txt", O_CREAT | O_WRONLY, 0644));
    if (symlink("d1/d2", "lnk") != 0) perror("symlink");
    ino_t a = walk("d1/d2/f.txt"), b = walk("lnk/f.txt");
    printf("same file at the end? %s\n", a == b ? "yes, same inode" : "no");
    return 0;
}

walk d1/d2/f.txt
  1. d1     directory
  2. d2     directory
  3. f.txt  regular file
  components looked up: 3
walk lnk/f.txt
  1. lnk    symlink, follow -> d1/d2
  2. f.txt  regular file
  components looked up: 2
same file at the end? yes, same inode

শেষে আরেকটি সূক্ষ্ম বিষয়, যা অভিজ্ঞদেরও ধোঁকা দেয়: kernel-এর .. “physical” — symlink অনুসরণের পর আসল জায়গার মা-directory. ধরুন ~/proj একটি symlink যা /etc দেখায়। ls ~/proj/.. দেখাবে /-এর ভেতর, আপনার home নয়! অথচ bash-এর cd ~/proj/.. আপনাকে home-এ ফেরত আনে, কারণ shell নিজে “logical” path মনে রাখে (cd -P দিলে physical). নিচের ছোট simulator একটি কাল্পনিক file system-এ namei-র সব নিয়ম — symlink, .., mount আর ELOOP — একসাথে দেখায়:

// A tiny namei: inode table, symlinks, "..", and one mounted USB file system
const I = {
  2:  { e: { home: 10, etc: 30, mnt: 40 } },  10: { e: { rahim: 11 } },    // "/" and /home
  11: { e: { docs: 12, latest: 14, proj: 15, loop: 16 } },  12: { e: { 'notes.txt': 13 } },
  14: { to: 'docs/notes.txt' },  15: { to: '/etc' },  16: { to: 'loop' },   // symlinks
  30: { e: { hosts: 31 } },  40: { e: { 'old.txt': 41 } },                 // /etc and /mnt
  900: { e: { 'photo.jpg': 901 } },                                        // root of the USB fs
};                                    // inodes not listed (13, 31, 41, 901) are regular files
const mounts = { 40: 900 };           // as if: mount /dev/sdb1 /mnt
let follows = 0;
function walk(path, stack) {
  stack = path.startsWith('/') ? [2] : stack.slice();
  const parts = path.split('/').filter(Boolean);
  for (let i = 0; i < parts.length; i++) {
    const name = parts[i], dir = I[stack[stack.length - 1]];
    if (!dir || !dir.e) return 'ENOTDIR';
    if (name === '.') continue;
    if (name === '..') { if (stack.length > 1) stack.pop(); continue; }
    let ino = dir.e[name];
    if (ino === undefined) return 'ENOENT';
    if (mounts[ino]) ino = mounts[ino];                 // cross into the mounted fs
    if (I[ino] && I[ino].to) {                          // a symlink: splice its path in
      if (++follows > 40) return 'ELOOP';               // Linux gives up after 40
      return walk([I[ino].to, ...parts.slice(i + 1)].join('/'), stack);
    }
    stack.push(ino);
  }
  return 'inode ' + stack[stack.length - 1];
}
for (const p of ['/home/rahim/docs/notes.txt', '/home/rahim/latest', '/home/rahim/proj/hosts',
    '/home/rahim/proj/..', '/mnt/photo.jpg', '/mnt/old.txt', '/mnt/..', '/home/rahim/loop',
    '/home/rahim/docs/notes.txt/x', '//home/./rahim/../rahim/docs']) {
  follows = 0;
  console.log(p.padEnd(30), '->', walk(p, [2]).padEnd(10), 'symlinks followed:', follows);
}

/home/rahim/docs/notes.txt     -> inode 13   symlinks followed: 0
/home/rahim/latest             -> inode 13   symlinks followed: 1
/home/rahim/proj/hosts         -> inode 31   symlinks followed: 1
/home/rahim/proj/..            -> inode 2    symlinks followed: 1
/mnt/photo.jpg                 -> inode 901  symlinks followed: 0
/mnt/old.txt                   -> ENOENT     symlinks followed: 0
/mnt/..                        -> inode 2    symlinks followed: 0
/home/rahim/loop               -> ELOOP      symlinks followed: 41
/home/rahim/docs/notes.txt/x   -> ENOTDIR    symlinks followed: 0
//home/./rahim/../rahim/docs   -> inode 12   symlinks followed: 0

৭ · Mounting — অনেক file system, একটিই গাছ

আপনার ল্যাপটপে হয়তো একটি SSD, একটি USB stick, আর kernel-এর তৈরি কয়েকটি “কাল্পনিক” file system (/proc, /sys) আছে। Windows প্রতিটি volume-কে একটি আলাদা অক্ষর দেয় — C:, D:, E:. Unix-এর দর্শন ভিন্ন: একটিই গাছ, যার শিকড় /, আর প্রতিটি নতুন file system গাছের কোনো একটি directory-তে “জুড়ে দেওয়া” হয়। এই জুড়ে দেওয়ার নাম mount, আর ঐ directory হলো mount point.

Kernel প্রতিটি mount-এর রেকর্ড রাখে একটি mount table-এ (Linux-এ প্রতিটি mount namespace-এর নিজস্ব; container এ কারণেই আলাদা দৃশ্য পায় — পর্ব ৫১)। নিচে একটি USB stick-কে /mnt-এ mount করার পুরো গল্প:

আরও কয়েক রকম mount

• Bind mount: mount --bind /srv/data /home/rahim/data — নতুন file system নয়, একটি বিদ্যমান directory-কে আরেক জায়গায় আবার দেখানো। symlink-এর মতো শোনায়, কিন্তু kernel-এর mount স্তরে হয়, তাই .., chroot আর container-এর ভেতরেও ঠিক থাকে। Docker-এর -v /host/dir:/app/data আসলে একটি bind mount.
• Automount: path প্রথমবার ছোঁয়ার মুহূর্তে mount, অনেকক্ষণ ব্যবহার না হলে খুলে ফেলা — autofs বা systemd-এর .automount unit. অফিসের নেটওয়ার্ক-শেয়ার (NFS) বা কম-ব্যবহৃত ডিস্কের জন্য উপযোগী।
• কাল্পনিক file system: procfs (/proc), sysfs (/sys), tmpfs (RAM-এ থাকা ফাইল, যেমন /dev/shm, অনেক distro-য় /tmp), cgroup2 — এদের পেছনে কোনো ডিস্ক নেই, kernel পড়ার মুহূর্তে উত্তর বানায়।
• Windows-এ: drive letter-ই মূল পদ্ধতি, তবে NTFS একটি volume-কে অন্য volume-এর একটি খালি ফোল্ডারেও mount করতে পারে (Disk Management-এ “Mount in the following empty NTFS folder”, বা mountvol) — Unix-এর mount point-এর কাছাকাছি।

এবার এই অনলাইন রানারের container নিজেই কী দেখে, দেখি। /proc/mounts হলো এই process-এর mount namespace-এর mount table, আর findmnt সেটি গাছ বা কলাম আকারে সুন্দর করে দেখায় (না থাকলে script জানাবে):

echo "== first 6 lines of /proc/mounts (device  mount-point  type  options ...) =="
head -n 6 /proc/mounts | cut -c1-90
echo "== mounts per file-system type =="
awk '{print $3}' /proc/mounts | sort | uniq -c | sort -rn
echo "== which file system holds these paths? =="
for d in / /proc /sys /dev /tmp "$PWD"; do
  printf '%-22s %s\n' "$d" "$(stat -f -c %T "$d")"
done
echo "total mounts visible to this process: $(wc -l < /proc/self/mounts)"
if command -v findmnt >/dev/null; then findmnt -n -o TARGET,FSTYPE,SOURCE /; else echo "findmnt not installed"; fi

== first 6 lines of /proc/mounts (device  mount-point  type  options ...) ==
/dev/vda2 /home/wandbox ext4 rw,relatime 0 0
/dev/vda2 /run/podman-init ext4 ro,relatime 0 0
/dev/vdb1 /opt/wandbox ext4 ro,noatime 0 0
/dev/vda2 /etc/resolv.conf ext4 rw,relatime 0 0
/dev/vda2 /etc/hosts ext4 rw,relatime 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=64000k,uid=1000,gid=1000,inode64 0
== mounts per file-system type ==
     10 devtmpfs
      7 proc
      7 ext4
      6 tmpfs
      1 sysfs
      1 overlay
      1 mqueue
      1 devpts
      1 cgroup2
== which file system holds these paths? ==
/                      overlayfs
/proc                  proc
/sys                   sysfs
/dev                   tmpfs
/tmp                   overlayfs
/home/wandbox          ext2/ext3
total mounts visible to this process: 35
/      overlay overlay

৮ · VFS — একই read() কীভাবে ext4, NFS, procfs আর FUSE-এ চলে

আপনার প্রোগ্রাম read(fd, buf, 100) লেখে। fd-টি হতে পারে SSD-র ext4 ফাইল, অফিসের সার্ভারের NFS ফাইল, /proc/cpuinfo (যার কোনো ডিস্কই নেই), অথবা FUSE দিয়ে বানানো Google Drive-এর একটি ফাইল। প্রোগ্রাম কোনো পার্থক্য জানে না। এই জাদুর নাম VFS — virtual file system স্তর।

VFS কয়েকটি সাধারণ বস্তু সংজ্ঞায়িত করে, আর প্রতিটির সাথে একটি operation table — function pointer-এর একটি struct, যা প্রতিটি file system নিজের function দিয়ে ভরে (C-তে object-oriented নকশা):

struct file_operations {                 /* one table per kind of file */
    loff_t  (*llseek)    (struct file *, loff_t, int);
    ssize_t (*read)      (struct file *, char __user *, size_t, loff_t *);
    ssize_t (*write)     (struct file *, const char __user *, size_t, loff_t *);
    ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
    ssize_t (*write_iter)(struct kiocb *, struct iov_iter *);
    int     (*iterate_shared)(struct file *, struct dir_context *);  /* readdir */
    int     (*mmap)      (struct file *, struct vm_area_struct *);
    int     (*open)      (struct inode *, struct file *);
    int     (*fsync)     (struct file *, loff_t, loff_t, int datasync);
    /* ... many more ... */
};

const struct file_operations ext4_file_operations = {   /* ext4 fills it in */
    .llseek     = ext4_llseek,
    .read_iter  = ext4_file_read_iter,
    .write_iter = ext4_file_write_iter,
    .mmap       = ext4_file_mmap,
    .open       = ext4_file_open,
    .fsync      = ext4_sync_file,
};

ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
{
    if (!(file->f_mode & FMODE_READ))
        return -EBADF;
    /* (permission and range checks omitted) */
    if (file->f_op->read)
        return file->f_op->read(file, buf, count, pos);      /* jump into the fs */
    if (file->f_op->read_iter)
        return new_sync_read(file, buf, count, pos);
    return -EINVAL;
}

অর্থাৎ read() system call → vfs_read() → file->f_op->read_iter — আর কোন function সেখানে বসানো, তা ঠিক হয়েছিল open()-এর সময়, ফাইলটি কোন file system-এর তা দেখে। এভাবে:

• ext4: page cache দেখে, না থাকলে ডিস্কের ব্লক পড়ার অনুরোধ (পর্ব ৩৯-৪০-এর I/O পথ)।
• NFS: নেটওয়ার্কে সার্ভারকে RPC পাঠায় (পর্ব ৫৩)।
• procfs: kernel-এর ভেতরের তথ্য দিয়ে সেই মুহূর্তে লেখা তৈরি করে — এ জন্যই ls -l /proc/cpuinfo আকার ০ দেখায়, অথচ cat করলে অনেক লাইন আসে।
• FUSE: kernel-এর FUSE module অনুরোধটি /dev/fuse দিয়ে একটি সাধারণ user-space প্রোগ্রামের কাছে পাঠায় (যেমন sshfs), উত্তর এলে ফেরত দেয়। ফলে root অধিকার বা kernel কোড ছাড়াই নতুন file system লেখা যায় — বিনিময়ে প্রতিটি অনুরোধে বাড়তি context switch.

Windows-এও একই চিন্তা, ভিন্ন রূপে: I/O Manager একটি অনুরোধকে IRP (I/O request packet) বানিয়ে সঠিক file system driver-এর (NTFS, FAT, ReFS) কাছে পাঠায়, আর filter driver (যেমন antivirus) মাঝখানে বসতে পারে (পর্ব ৫৬)।

৯ · Filesystem Hierarchy Standard — Linux-এর ফোল্ডার-মানচিত্র

প্রতিটি Linux distro-তে /etc-এ configuration আর /home-এ user-দের ফাইল কেন? কারণ একটি সাধারণ চুক্তি আছে — Filesystem Hierarchy Standard (FHS), যার সর্বশেষ বড় সংস্করণ ৩.০ (২০১৫, Linux Foundation). পর্ব ০৩-এ মানচিত্রটি এক নজরে দেখেছেন; এখানে প্রতিটি directory কোন file system বা mount-এর সাথে জড়িত, সেই চোখে দেখি:

Windows-এ তুলনীয় জায়গা: C:\Windows (OS), C:\Program Files (প্রোগ্রাম, অনেকটা /usr), C:\Users (/home), C:\ProgramData (কিছুটা /var আর /etc-এর মিশ্রণ), আর configuration-এর বড় অংশ registry-তে (পর্ব ৫৬)। macOS-এ user-দের ফাইল /Users-এ, আর ভেতরে BSD-ধাঁচের /etc, /usr, /var আছে।

১০ · AI-এর যুগে file system-এর প্রশ্ন — উত্তর যাচাই

“Linux-এ একটি ফোল্ডার অন্য জায়গায় দেখাতে চাই” — AI খুব দ্রুত ln -s বা mount --bind লিখে দেবে। কিন্তু link আর mount-এর ভুল সাধারণত সাথে সাথে ধরা পড়ে না; কয়েক মাস পরে backup-এ, deploy-এ বা কারও ফাইল মোছার সময় ধরা পড়ে। AI-এর সাধারণ ভুলগুলো:

AI-এর দেওয়া link বা mount-এর পরামর্শ ব্যবহারের আগে — চেকলিস্ট

• কমান্ডটি আমার OS আর distro-র জন্য (Linux না macOS না Windows), আর man page-এ argument-এর ক্রম মিলিয়েছি
• প্রথমে একটি খালি পরীক্ষার ফোল্ডারে চালিয়ে ls -li, readlink -f দিয়ে ফল দেখেছি
• দুই জায়গা একই file system-এ কি না দেখেছি (stat -f -c %T, findmnt -T path)
• permission-এর সমস্যায় আগে namei -l দিয়ে কোন component আটকাচ্ছে খুঁজেছি — 777 দিইনি
• rm -r, umount -l বা /etc/fstab বদলের আগে backup আর ফেরার পথ ঠিক করেছি
• backup টুল symlink আর hard link কীভাবে সামলায় (rsync -H, tar), একটি ছোট পরীক্ষায় দেখেছি