We recognize that one-size-fits-all file systems are insufficient in many cases. Specialized file systems are often proposed but rarely implemented. Four example domains include:
Researchers and developers have always needed an environment where they can quickly prototype and test new file system ideas. Several earlier works attempted to provide the necessary flexibility. Apollo's I/O system was extendible through user-level libraries that changed the behavior of the application linking with them [Rees86]; now, modern support for shared libraries [Gingell87a] permits new functionality to be loaded by the run-time linker. One of the first attempts to extend file system functionality was ``watchdogs'' [Bershad88], a mechanism for trapping file system operations and running user-written code as part of the operation.
Vnode stacking was first implemented by Rosenthal (in SunOS 4.1) around 1990 [Rosenthal90]. His work was both the first implementation of the plugability concept and also a clean-up effort in response to changes that had been required to support integration of SunOS and System V and to merge the file system's buffer cache with the virtual memory system. Because it focused on the universally available vnode interface, Rosenthal's stacking model was not ad hoc, unlike earlier efforts, and held promise as a ``standard'' file system extension mechanism.
With vnode stacking, a vnode now represents a file open in a particular file system. If N file systems are stacked, a single file is represented by N vnodes, one for each file system. The vnodes are chained together. A vnode interface operation proceeds from the head of the chain to the tail, operating on each vnode, and aborting if an error occurs. This mechanism, which is similar to the way Stream I/O modules [Ritchie84] operate, is depicted in Figure fig-vnode-chain.
This simple interface alone was capable of combining several instances of existing UFS or NFS file systems to provide replication, caching, and fall-back file systems, among other services. Rosenthal built a prototype of his proposed interface in the SunOS 4.1 kernel, but was not satisfied with his design and implementation for several reasons: locking techniques were inadequate, the VFS interface had not been redesigned to fit the new model, multi-threading issues where not considered, and he wanted to implement more file system modules so as to get more experience with the interface. Rosenthal's interface was never made public or incorporated into Sun's operating systems.
A few similar works followed Rosenthal, such as further prototypes for extended file systems in SunOS [Skinner93], and the Ficus layered file system [Guy90,Heidemann91] at UCLA.