Virtual File System (VFS)

Modern operating systems face a remarkable challenge: users and applications expect to read files, write files, list directories, and navigate file hierarchies—all without caring whether their data resides on an ext4 partition, an NTFS volume, an NFS network share, a FAT-formatted USB drive, or even a pseudo-filesystem like /proc. The system call open("/home/user/document.txt", O_RDONLY) should work identically regardless of the underlying storage technology.

This creates an engineering problem of significant complexity. Each file system has radically different on-disk structures, metadata formats, allocation strategies, and performance characteristics. ext4 uses inodes and block groups; NTFS uses the Master File Table; FAT uses the File Allocation Table; ZFS uses a transactional copy-on-write model. How can an operating system provide a uniform interface to applications while simultaneously supporting this diverse ecosystem of storage technologies?

The answer is the Virtual File System (VFS)—one of the most elegant and important abstraction layers in operating system design.

The Virtual File System (VFS) is a software abstraction layer within the kernel that provides a uniform interface to the file system namespace, regardless of the underlying file system implementation. It is the kernel subsystem that interprets system calls like open(), read(), write(), close(), stat(), readdir(), and dispatches them to the appropriate file system driver.

Key Insight: The VFS is not a file system itself. It stores no data on disk. Instead, it defines a contract—a set of data structures and function pointers—that all file systems must implement. When an application calls read(), the VFS translates that call into the corresponding operation for ext4, XFS, NFS, or whatever file system actually holds the data.

Formal Definition:

The Virtual File System is the kernel subsystem that:

1. Presents a unified API to user-space processes for all file and directory operations
2. Defines abstract data types (superblock, inode, dentry, file) that represent file system entities
3. Dispatches operations to concrete file system implementations through function pointers
4. Manages the namespace by assembling file systems into a single directory hierarchy via mounting
5. Provides caching for directory entries (dentry cache) and inode metadata (inode cache)

This design achieves separation of concerns: application programmers write portable code against a stable API, while file system developers implement specific storage formats without modifying the kernel's core I/O path.

The VFS concept emerged from practical necessity in the 1980s as operating systems needed to support multiple file system types simultaneously.

The Problem: Early Unix systems had a single, hardcoded file system (often the original Unix File System or variations). When Sun Microsystems developed NFS (Network File System) in 1984, they faced a challenge: how could the kernel support both local disk access and remote network file access without duplicating the entire file I/O subsystem?

Sun's Solution: Sun engineers created what they called the vnode interface (virtual node interface)—the first VFS implementation. The vnode abstraction represented any file-like entity, whether local or remote, with a common set of operations. This allowed NFS to plug into the kernel alongside the local file system.

The Vnode Model:

• A vnode (virtual inode) is a kernel data structure representing an open file
• Each vnode contains a pointer to vnode operations—functions like read, write, lookup
• Different file systems provide their own vnode operation implementations
• The kernel calls through the vnode interface without knowing the underlying implementation

The VFS embodies a fundamental principle in systems design: abstraction hides complexity behind stable interfaces. Let's examine what this means concretely.

Without VFS:

// Hypothetical world without VFS abstraction
if (file_system_type == FS_EXT4) {
    ext4_open(path, flags);
} else if (file_system_type == FS_NTFS) {
    ntfs_open(path, flags);
} else if (file_system_type == FS_NFS) {
    nfs_open(path, flags);
} else if (file_system_type == FS_ZFS) {
    zfs_open(path, flags);
}
// ... repeated for EVERY operation, in EVERY application

This approach is unmaintainable. Every application would need knowledge of every file system. Adding a new file system would require modifying every program.

With VFS:

// Application code — identical regardless of file system
int fd = open("/path/to/file", O_RDONLY);
read(fd, buffer, size);
close(fd);

The application is completely isolated from file system details. The kernel's VFS layer handles dispatch to the appropriate driver.

The VFS sits between user-space applications and concrete file system implementations, serving as the kernel's file system dispatcher and cache manager. Understanding its position in the software stack is crucial.

Layer Stack (Top to Bottom):

1. User-Space Applications — Programs using standard C library functions (fopen, fread, fprintf)
2. C Library (libc) — Translates library calls to system calls (write() syscall from fprintf)
3. System Call Interface — Kernel entry point for file operations
4. Virtual File System (VFS) — Dispatches to appropriate file system, manages caches
5. File System Drivers — ext4, XFS, btrfs, NFS, FAT, etc.
6. Block Layer / Network Layer — Generic I/O for block devices or network sockets
7. Device Drivers — Hardware-specific code for disks, NICs, etc.
8. Hardware — Physical storage media, network interfaces

Key Observations:

1. Single Entry Point: All file operations, regardless of destination, enter through the same system call interface and pass through VFS.

2. Uniform Dispatch: VFS uses function pointers in the inode, dentry, and file structures to route operations to the correct driver.

3. Diverse Backends: Notice how some file systems go to the block layer (ext4, XFS), others to the network stack (NFS), yet others to user-space (FUSE), and pseudo file systems access kernel data directly (procfs).

4. VFS as Unifier: Despite these vastly different backends, the VFS makes them all look the same to applications.

The VFS layer performs several critical functions that go beyond simple dispatch. Understanding these responsibilities reveals why VFS is so central to kernel operation.

One of VFS's most complex and performance-critical tasks is pathname resolution—converting a path string like /home/alice/projects/kernel/vfs.c into an in-memory inode structure. This process involves multiple steps, caches, and potential mount point crossings.

The namei Algorithm (name-to-inode):

1. Start Point: For absolute paths, start at the root dentry (/). For relative paths, start at the process's current working directory.

2. Component Iteration: Split the path by / and process each component (home, alice, projects, etc.) left to right.

3. For Each Component:

   • Dentry Cache Lookup: Check if this component is in the dcache. Cache hit? Use the cached dentry/inode without disk I/O.
   • Cache Miss: Call the parent directory's lookup operation (e.g., ext4_lookup) to read the directory and find the entry.
   • Permission Check: Verify execute permission on the directory (required for traversal).
   • Special Cases: Handle . (current), .. (parent), symbolic links (follow or not based on flags).
   • Mount Point Check: If this dentry is a mount point, switch to the root dentry of the mounted file system.

4. Final Component: The last component may be the target file/directory, or for operations like open() with O_CREAT, it may not exist yet.

5. Return: Return the final dentry and inode, or an error if resolution fails.

Performance Insight:

For a path like /usr/local/bin/python, the kernel must resolve 5 components. On a cold cache, this might require 5 disk reads. With a warm dcache, all 5 lookups come from memory in nanoseconds. This is why the dcache is sized generously and uses efficient hash-table lookup—path resolution happens millions of times per second on busy systems.

Mount Point Traversal:

Mount points are transparent to path resolution. If /mnt/usb has a FAT file system mounted, resolving /mnt/usb/document.txt automatically crosses from whatever file system /mnt is on (probably ext4) into the FAT file system. The VFS maintains a mount hash table that maps dentries to mount information, enabling O(1) mount point detection.

The VFS abstraction is so powerful that many things that aren't traditional "file systems" are implemented as file systems. These pseudo-filesystems or virtual filesystems use the VFS interface to expose kernel data, device interfaces, and computed information as files and directories.

Philosophy: In Unix, "everything is a file." The VFS makes this philosophy implementable in practice.

Why Implement as File Systems?

1. Universal Interface: Any tool that reads files can inspect kernel state. cat /proc/cpuinfo works without special programs.

2. Permissions: Standard Unix permissions apply. chmod 600 /proc/self/status restricts who can read process info.

3. Composability: Shell pipelines, scripting, existing tools all work: grep MemFree /proc/meminfo | awk '{print $2}'.

4. No New APIs: No need for special system calls or ioctls. Read and write are sufficient.

5. Discoverability: Users can ls directories to see what's available.

We've explored the Virtual File System abstraction layer in depth. Let's consolidate what we've learned:

What's Next:

Now that we understand what VFS is and why it exists, we'll examine the common interface it presents—the specific system calls, data structures, and operations that form the VFS contract. This will show you exactly what a file system must implement to plug into the VFS layer.