Famously, everything is a file in Unix, at least in the original Research Unix, such as V7 Unix (BSD Unix deviated from this for network stuff). Files were files, directories were files, disks were files, serial lines were files, and so on. This was a pretty revolutionary idea at the time. However, this was not implemented inside the kernel in any general way; instead, things knew that there were various types of file objects and inodes, and handled them specifically. As part of this, early Unixes had no concept of there being multiple types of filesystems. There was one type of on-disk filesystem, whatever it was, and reads and writes of regular files were fairly hard-coded.

(You can see all of this in the V7 rdwr() function in sys2.c and eg readi() in rdwri.c. This continues to be the case in 4.2 BSD, cf rwip() in sys_inode.c.)

This worked out okay even in 4.2 BSD, because while 4.2 BSD changed the filesystem format, it still only had one type of filesystem. Then Sun came up with NFS and found themselves with a problem; their kernel needed to support two different filesystems at once, the BSD FFS/UFS for local disks and NFS for networked filesystems. So Sun invented the idea of the Virtual Filesystem Switch (VFS). VFS added a layer of indirection to the kernel's internal operations on mounted filesystems. Each different type of filesystem had a bunch of function pointers for various operations, and now when the kernel wanted to read data from a regular file, it didn't call one function to map the file offset to a block number and then another one to read the block number from disk (how V7 and 4.2 BSD did it). Instead the kernel indirectly called a per-filesystem 'read this data from this file' function. On a local UFS/FFS filesystem, this did the same block mapping and device reading thing as before, but on a NFS mount, it made RPC calls over the network.

(V8 also had the idea of the VFS, as the "file system switch". I think that Sun's NFS and V8 were basically contemporary, so it's quite possible that the VFS idea was in the Unix air at the time as an obvious development.)

One critical thing that the VFS did was it opened the door for virtual filesystems, filesystems that did not have a concrete implementation that stored things on disk (even if it was on another machine you were making RPC requests to). Virtual filesystems could make up their contents on the fly, both the contents of files and the contents of directories. In modern Unix, virtual filesystems are used to implement a number of important things, although just what depends on the Unix.

(Plan 9 from Bell Labs took the idea of everything being a (virtual) filesystem about as far as you could ask. Famously, the window system was exposed and manipulated as a filesystem, and programs could do this themselves to expose their own operations, as acme did.)

Today the idea of Unix virtual filesystems is everywhere (pretty much everyone has /proc, for example). However, it had to be invented and then it took a bit of time for it to become pervasive and for kernel developers to become comfortable with exploiting its capabilities. As a practical matter, waiting for the VFS turns out to be a blocking factor on some interesting and obvious seeming Unix capabilities, but that's for another entry.