the virtual filesystem (VFS)

Imagine you can open a file the same way whether it lives on a hard disk, on a USB stick formatted differently, on a network share, or even on something that is not a real disk at all (like /proc). You type open() and read() and it just works. That sameness is not an accident: inside the kernel sits a translation layer that hides the differences between all those storage systems behind one common set of operations. That layer is the virtual filesystem, usually shortened to VFS.

Concretely, VFS defines a handful of in-memory objects that every real filesystem must present: a superblock (one per mounted filesystem, describing the whole thing), an inode (one per file, holding its metadata), a dentry (one per name in a directory, linking a name to an inode), and a file (one per open file descriptor, holding the current read/write position). Each real filesystem - ext4, XFS, Btrfs, FAT, NFS - supplies a table of function pointers saying how to actually carry out an operation. So when you call read(fd, ...), the kernel finds the file object, follows its inode, and calls that inode's read operation, which dispatches into the right filesystem's code. The application never sees which filesystem answered.

Why it matters: VFS is the reason a single set of POSIX calls (open, read, write, close, stat, rename) works across dozens of utterly different storage backends, and the reason you can mount one filesystem inside another's directory tree. A common misconception is that VFS is itself a filesystem that stores data - it stores nothing on disk. It is purely an abstraction layer of function pointers and cached objects in RAM; the real bytes live in whatever concrete filesystem sits below it.