The Virtual Filesystem (VFS): One API to Rule Them All

A Universal Translator

Imagine you speak English and need to give instructions to workers who speak French, Spanish, and Mandarin. You could hire a separate translator for each language, but a smarter approach is to have one universal translator who routes your instructions to the right specialist. That is exactly what the VFS does.

The Virtual Filesystem (VFS) is a kernel abstraction layer that provides a single, unified set of system calls — open(), read(), write(), close(), stat() — regardless of what filesystem is actually mounted underneath. Your application does not know or care whether it is writing to an ext4 partition on a local SSD, an XFS volume on a SAN, or a FUSE-based filesystem backed by an S3 bucket. The VFS handles the routing.

The VFS defines a set of abstract objects and operations:

• inode: Represents a file's metadata (permissions, size, timestamps, pointers to data blocks). Every file has exactly one inode.
• dentry (directory entry): Represents a name-to-inode mapping. The path /home/alice/notes.txt is resolved by walking a chain of dentries.
• file: Represents an open file descriptor — the state of a specific process's open handle to an inode.
• superblock: Represents a mounted filesystem instance — its type, block size, and root inode.

Each concrete filesystem (ext4, XFS, tmpfs) registers its own implementations of these operations with the VFS. When you call write(), the VFS looks up the correct filesystem's write function pointer and calls it.

Key insight for senior engineers: The dentry cache (dcache) is a critical performance component. When you stat() a file repeatedly, the kernel does not re-walk the directory tree each time — it caches the dentry. On systems with millions of files (like large build caches or container image layers), dcache pressure can become a real bottleneck, visible as elevated sys CPU time.