Virtual Filesystem Switch — কেন একটাই read() ext4, NFS, tmpfs আর FUSE-এ সমানভাবে কাজ করে

চারটা কেন্দ্রীয় object

VFS পুরোটাই চারটা C struct-এর উপর দাঁড়িয়ে। প্রতিটা একটা ভিন্ন প্রশ্নের উত্তর দেয়:

এই চারটার সম্পর্কটা মনে রাখার সহজ উপায় — inode ফাইল সম্পর্কে, dentry নাম সম্পর্কে, file আপনার সেশন সম্পর্কে, আর superblock গোটা filesystem সম্পর্কে। একই inode-কে একাধিক dentry নির্দেশ করতে পারে (hard link — গত লেসনের বিষয়), আর একই inode-এ একাধিক প্রক্রিয়ার একাধিক struct file খোলা থাকতে পারে, প্রতিটার নিজস্ব offset।

                         struct super_block
                         (একটা mounted filesystem)
                                  │
                    ┌─────────────┴─────────────┐
                    │                             │
            struct dentry                  struct dentry
            name: "etc"                     name: "passwd"
            inode: 2 (dir)                  inode: 41231
                    │                             │
                    └──────────┬──────────────────┘
                                │  (parent-child, গাছ গঠন করে)
                                ▼
                         struct inode #41231
                         mode, uid, gid, size,
                         i_op (inode_operations)
                                │
              ┌─────────────────┴─────────────────┐
              ▼                                     ▼
     struct file (PID 1234, fd 3)          struct file (PID 5678, fd 7)
     f_pos = 512                            f_pos = 0
     f_op (file_operations)                 f_op (file_operations)

Operations struct — C-তে interface/vtable

প্রতিটা object-এর সাথে একটা “operations” struct জোড়া থাকে — নিছক function pointer-এর একটা তালিকা। এটাই সেই জায়গা যেখানে “polymorphism” শব্দটা আক্ষরিক অর্থে প্রযোজ্য, যদিও C-তে কোনো class বা virtual keyword নেই।

/* সরলীকৃত -- linux/fs.h */
struct file_operations {
    ssize_t (*read)  (struct file *, char __user *, size_t, loff_t *);
    ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
    int     (*open)  (struct inode *, struct file *);
    int     (*release)(struct inode *, struct file *);
    loff_t  (*llseek)(struct file *, loff_t, int);
    long    (*unlocked_ioctl)(struct file *, unsigned int, unsigned long);
    /* ... আরও প্রায় ৩০টা ফিল্ড ... */
};

ext4 এই struct-টা এভাবে পূরণ করে:

/* fs/ext4/file.c (সরলীকৃত) */
const struct file_operations ext4_file_operations = {
    .llseek   = ext4_llseek,
    .read_iter = ext4_file_read_iter,
    .write_iter = ext4_file_write_iter,
    .open     = ext4_file_open,
    .release  = ext4_release_file,
    /* ... */
};

আর tmpfs-এর জন্য সম্পূর্ণ ভিন্ন ফাংশনগুলো একই struct-এর একই স্লটে বসে:

/* mm/shmem.c (সরলীকৃত) */
const struct file_operations shmem_file_operations = {
    .llseek   = shmem_file_llseek,
    .read_iter = shmem_file_read_iter,   /* সরাসরি page cache থেকে -- disk I/O নেই */
    .write_iter = generic_file_write_iter,
    /* ... */
};

sys_read()-এর ভেতরের কোড শুধু এটুকু করে:

/* সরলীকৃত -- fs/read_write.c */
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos) {
    if (!file->f_op->read_iter)
        return -EINVAL;
    return file->f_op->read_iter(...);   /* ★ indirect call -- এখানেই polymorphism */
}

এই একটা ->read_iter(...) কলটাই পুরো VFS-এর হৃদয়। file->f_op pointer-টা open() করার সময় সেট হয়ে গেছে — ext4 file হলে ext4-এর ফাংশন, tmpfs হলে tmpfs-এর, NFS হলে network round-trip করা ফাংশন। কলার-এর কোড (VFS, syscall layer) কখনো জানে না কোনটা চলছে, আর জানারও দরকার নেই।

মূল পার্থক্য শুধু এটুকু: C++/Java-তে compiler vtable-টা লুকিয়ে বানায়, C-তে kernel developer নিজের হাতে struct পূরণ করেন। প্রক্রিয়াটা একই — একটা indirect function call দিয়ে “কোন বাস্তবায়ন চলবে” সিদ্ধান্তটা compile-time থেকে run-time-এ ঠেলে দেওয়া। Level 5-এর compiler module-এ দেখব কীভাবে একটা C++ compiler এই একই struct স্বয়ংক্রিয়ভাবে তৈরি করে।

Dentry cache — কেন এটা ছাড়া path lookup অসহনীয় ধীর হতো

একটা path resolve করা মানে কী, সেটা প্রথমে দেখা যাক। /etc/nginx/sites-enabled/default পড়তে গেলে kernel-কে প্রতিটা component ধাপে ধাপে resolve করতে হয়:

১. root inode (২) থেকে "etc" খোঁজো      → directory block পড়ো, "etc" এন্ট্রি বের করো
২. "etc"-এর inode থেকে "nginx" খোঁজো      → আরেকটা directory block পড়ো
৩. "nginx"-এর inode থেকে "sites-enabled"  → আরেকটা directory block পড়ো
৪. "sites-enabled"-এর inode থেকে "default" → আরেকটা directory block পড়ো

চারটা component, চারটা directory read — আর প্রতিটা read মানে সম্ভাব্য একটা disk I/O (৫-১০ ms, যদি cache-এ না থাকে)। একটা গভীর path (Kubernetes বা npm-এর মতো সিস্টেমে ১০-১৫ level গভীর path সাধারণ) হলে এই costটা আক্ষরিক অর্থে unusable হয়ে যেত — প্রতিটা open() কল কয়েক দশ মিলিসেকেন্ড লাগত।

এর সমাধান dentry cache (dcache) — প্রতিটা resolve করা (parent dentry, name) → dentry জোড়া একটা in-memory hash table-এ রেখে দেওয়া। দ্বিতীয়বার একই path resolve করলে প্রতিটা ধাপ hash lookup — কোনো disk I/O নেই।

এই সংখ্যাটাই এই লেসনের experiment সেকশনে সরাসরি মাপা হবে drop_caches দিয়ে।

Mount tree — আলাদা filesystem একটা গাছে জোড়া লাগা

mount-এর ধারণাটা VFS-এর দ্বিতীয় বড় কৌশল। একটা mount আসলে করে এটুকুই: একটা নির্দিষ্ট dentry-কে (mount point) একটা ভিন্ন superblock-এর root dentry-র সাথে জুড়ে দেয়।

/                              (ext4 root superblock)
├── etc/                       (একই ext4)
├── home/                      (একই ext4)
├── proc/                      (◄── এখানে mount point, procfs superblock জোড়া)
│   ├── cpuinfo
│   └── 1234/
├── mnt/
│   └── usb/                   (◄── mount point, vfat superblock জোড়া)
└── tmp/                       (◄── mount point, tmpfs superblock জোড়া)

/proc-এ cd করলে VFS দেখে এটা একটা mount point — সেখান থেকে lookup procfs-এর superblock/dentry-তে “লাফ দেয়”। ব্যবহারকারীর কাছে এটা একটাই নিরবচ্ছিন্ন গাছ, কিন্তু প্রতিটা শাখা সম্পূর্ণ ভিন্ন backend হতে পারে। struct vfsmount এই জোড়াটা ধরে রাখে — কোন dentry কোন superblock-এর সাথে mount হয়েছে।

Bind mount (mount --bind /a /b) এই একই কৌশলের একটা প্রকরণ — নতুন কোনো superblock নয়, বরং একই filesystem-এর একটা dentry-কে গাছের অন্য একটা জায়গায় দ্বিতীয়বার দেখানো। Docker container-এর ভেতরে host-এর একটা ডিরেক্টরি “mount” হিসেবে দেখানো এভাবেই কাজ করে।

Mount namespace (unshare --mount, বা প্রতিটা container-এর নিজস্ব namespace) এক ধাপ আরও এগিয়ে — পুরো mount tree-র একটা কপি, process-ভেদে ভিন্ন হতে পারে। একটা container-এর ভেতরের প্রক্রিয়া / দেখে একরকম, host-এর প্রক্রিয়া দেখে আরেকরকম — অথচ underlying kernel একটাই, VFS object-গুলো একই কাঠামোর। এটাই container isolation-এর একটা মূল স্তম্ভ (namespace-এর বাকি অংশ — PID, network, user — Level 9-এর distributed systems module-এ)।

Pseudo-filesystem — ফাইল যা আসলে ফাইল নয়

VFS-এর সবচেয়ে চমৎকার প্রয়োগ হলো এমন filesystem যাদের পেছনে কোনো disk block-ই নেই।

এই প্রতিটার read_iter/write_iter implementation disk-এ কিছু access করে না — সরাসরি kernel-এর ভেতরের data structure পড়ে বা লেখে। cat /proc/1234/status আসলে PID 1234-এর task_struct থেকে সরাসরি ডেটা টেনে আনছে; disk-এ এমন কোনো ফাইল কখনোই ছিল না। এই কারণেই /proc/cpuinfo-র size প্রায়ই 0 দেখায় (ls -la-তে) — এর কোনো নির্দিষ্ট আকার নেই, প্রতিবার read করার সময় তৈরি হয়।

এটাই সেই কৌশল যা Unix দর্শনের “everything is a file” প্রতিশ্রুতিটা বাস্তবে টিকিয়ে রাখে — শুধু নিয়মিত ফাইলের জন্য নয়, বরং process, device, kernel configuration, এমনকি network socket-এর জন্যও একই read/write/ioctl interface। VFS-ই সেই স্তর যা এটা সম্ভব করে।

FUSE — userspace-এ filesystem, আর তার আসল খরচ

VFS-এর operations struct শুধু kernel কোডে পূরণ করা যায় তা নয় — FUSE (Filesystem in Userspace) একটা কৌশল যেখানে kernel-এর ভেতরের একটা generic fuse_file_operations implementation সব call একটা /dev/fuse character device-এর মধ্য দিয়ে userspace প্রক্রিয়ায় ফরওয়ার্ড করে দেয়।

ব্যবহারকারীর read(fd, buf, 4096)
        │
        ▼
   VFS: file->f_op->read_iter()   →   fuse_file_read_iter()  [kernel-এ]
        │
        ▼
   /dev/fuse-তে request লেখা, userspace প্রক্রিয়াকে জাগানো
        │
        ▼ (context switch, userspace-এ ফিরে যাওয়া)
   আপনার FUSE ডেমন: read() handler চলে, ফলাফল তৈরি করে
        │
        ▼
   /dev/fuse-তে উত্তর লেখা
        │
        ▼ (আরেকটা context switch, kernel-এ ফিরে যাওয়া)
   fuse_file_read_iter() উত্তর কপি করে ব্যবহারকারীকে দেয়

সাধারণ ext4-এ একটা read() মানে এক syscall, এক kernel-space function call। FUSE-এ একই read() মানে দুইটা পূর্ণ context switch (kernel → userspace ডেমন → kernel), প্রতিটা VFS operation-এর জন্য। এটাই FUSE-এর মৌলিক খরচ — সুবিধা (যেকোনো ভাষায়, memory-safe ভাষায়, সহজে filesystem লেখা) বনাম latency-র trade-off। একটা benchmark-নির্ভর সংখ্যা: sshfs (FUSE-ভিত্তিক) সাধারণত native ext4-এর তুলনায় ছোট ফাইলে ৩-১০× ধীর, কারণ প্রতিটা operation-এ এই round-trip যোগ হয়।