Virtual File System (VFS)

Calling read() on /etc/hostname returns the machine's name. Calling read() on /proc/cpuinfo returns CPU details. Calling read() on an NFS-mounted spreadsheet returns last quarter's numbers.

Same function. Same arguments. Completely different storage backends. One is a file on the local SSD. One does not exist on any disk -- the kernel fabricates it on the fly. One lives on a server three timezones away.

How does one syscall work for all of them? The answer is the Virtual File System.

What Actually Happens

Here is the path when read(fd, buf, 4096) is called:

1. The syscall lands in vfs_read()
2. The kernel looks at the struct file for the fd
3. It follows file->f_op->read_iter() — a function pointer
4. That pointer was set when the file was opened, based on the filesystem type
5. For ext4, it points to ext4_file_read_iter(). For NFS, nfs_file_read(). For procfs, proc_reg_read()

That's it. No switch statement. No filesystem detection at read time. Just one pointer dereference.

This indirection is set up at open() time. When the VFS resolves the path and finds the inode, the filesystem driver has already attached its function pointer table. Every subsequent operation on that fd goes through those pointers.

Under the Hood

VFS defines four core objects, each with an associated operations table.

The superblock (struct super_block + super_operations) represents a mounted filesystem instance. It holds the block size, root dentry, device reference, and operations like alloc_inode(), write_inode(), and statfs(). Every mount() call creates one.

The inode (struct inode + inode_operations) represents a file's identity and metadata — mode, uid, gid, size — plus operations like lookup(), create(), mkdir(), and permission(). This is the filesystem-independent version; the driver populates it from whatever on-disk format it uses.

The dentry (struct dentry + dentry_operations) represents a path component in the directory tree. Dentries form a cached tree used for path resolution. Their operations handle hash comparison and revalidation — critical for NFS, where server-side changes must be detected.

The file (struct file + file_operations) represents an open file instance. It holds the current offset, flags, and the actual I/O operations: read_iter(), write_iter(), mmap(), fsync(), and ioctl(). This is where the dispatch happens.

How filesystems plug in. Each driver registers via register_filesystem(), providing a file_system_type struct with a mount() callback. When mount() is called, the kernel finds the registered type in a global linked list, calls its mount callback to create the in-memory superblock, then grafts it into the mount tree at the specified mount point.

Path walking across mount points. The path walk algorithm uses the dentry cache to resolve each component. At each step, it checks if the current dentry is a mountpoint. If so, it transparently crosses into the mounted filesystem's root dentry. The boundary is invisible.

The dentry cache (dcache). This is one of the most performance-critical structures in the kernel. It's a hash table indexed by (parent dentry, name hash). A cache hit avoids disk I/O entirely. The kernel implements two walk modes: RCU-walk (lockless, no reference counts, blazing fast) for the common case, and ref-walk (locking, can sleep) as a fallback when the cache misses or a permission check needs to block. Hot path lookups are lock-free.

The unified page cache. Here's something elegant: the page cache is filesystem-agnostic. When vfs_read() is called, it typically goes through generic_file_read_iter(), which checks a per-inode page cache (an xarray of pages). Cache misses invoke the filesystem's readpage() or readahead() to populate pages. Because the cache is unified, memory pressure, dirty writeback, and sync/fsync work the same way whether the backend is ext4, NFS, or FUSE.

Common Questions

How does the kernel decide which filesystem driver handles an open() call?

It doesn't decide at open() time — the decision was made at mount() time. The kernel resolves the path component by component through the dentry cache. At each mount point, it transitions to the mounted filesystem's root dentry. Once the final component is reached, the inode's i_fop pointer (set during inode initialization by the filesystem driver) determines the file_operations table. The dispatch is baked into the inode, not computed per-call.

What happens when a filesystem is mounted on a non-empty directory?

The existing contents become hidden, not deleted. The dentry for the mount point gets a d_mounted flag, and path resolution switches to the mounted filesystem's root dentry instead of continuing into the original directory. Unmounting reveals the original contents. It is like placing a book on top of another -- the bottom book is still there, just not visible.

How does FUSE work from VFS's perspective?

FUSE registers as a regular filesystem type. Its inode and file operations point to FUSE kernel module functions. These functions translate VFS operations into FUSE protocol messages, write them to /dev/fuse, and block until the userspace daemon reads the message, processes it, and writes back a response. Every operation requires at least two context switches. That's the cost of running filesystem logic in userspace — and why FUSE is inherently slower than in-kernel filesystems.

Why does the dentry cache store entries for files that don't exist?

Because "does this file exist?" is one of the most common questions the kernel answers. The shell searches every directory in $PATH for each command. A build system checks dozens of include paths for each header. Without negative dentry caching, each failed lookup would hit disk. Negative dentries are cached with a timeout and evicted under memory pressure. They're a small investment that prevents enormous I/O waste.