a virtual file system

Imagine a universal power adapter that lets any plug fit any socket in any country. You hold one familiar plug; behind a standard face, the adapter quietly does whatever each country's wiring needs. The virtual file system is that adapter inside the kernel: it offers a single, uniform set of file operations to the rest of the system, while hiding the fact that the actual storage might be ext4, NTFS, FAT, a network share, or even something that is not a disk at all.

Here is how it works. When a program calls open, read, or write, the call enters the kernel and lands at the VFS layer, not at any specific file system. The VFS defines an abstract interface — a set of operations every file system must provide, working on generic objects: a superblock object for a mounted volume, an inode object for a file, a dentry for a directory entry, and a file object for an open file. Each real file-system type registers its own implementations of those operations. So read on a file in /home (ext4) calls ext4's read function, while read on a file in /mnt/usb (FAT) calls FAT's read function — but the program, and most of the kernel, only ever sees the common VFS interface. Mounting simply attaches a particular file system's superblock at a point in the unified directory tree.

This is the reason one Linux machine can have ext4, an NTFS USB stick, a CD-ROM's ISO9660, and a remote NFS share all visible in one seamless tree, all accessed through the same read and write calls. It is also why pseudo-file systems like /proc and /sys work: they implement the VFS interface but conjure their data on the fly instead of reading a disk. The honest cost is one extra layer of indirection on every file operation, which is tiny compared to the flexibility it buys.