VNodes: An Architecture for Multiple File Systems in Sun UNIX ============================================================= Summary ------- A classic level-of-indirection-trick paper. Describes an architecture for accomodating multiple file systems implementations (local, remote, non-unix) within a unix kernel while exposing a uniform file access interface at the system-call level. Motivation ---------- Support for multiple file system implementations within the kernel so that new file systems can be easily "plugged" in (i.e., without extensive rewriting of the file-system module of the kernel). Key idea -------- Any file system implementation can be abstracted into an object with a well-defined interface consisting of two sets of calls: (a) those that operate at the file system level, e.g. mount(), unmount(), sync(), etc., and (b) those that operate on individual files, e.g., open(), close(), mkdir() etc. Therefore, it is possible to accomodate multiple file systems in the kernel with a level of indirection. Details ------- File system module was split into two layers: file-system-dependant and file-system-independant. The split was done just above the unix inode layer. The file-system-independant layer is generally called the "vnode"-layer. There is one object per mounted file system, called "vfs". These objects are maintained as a linked list. The set of operations permitted on vfs's constitutes an interface which every file system implementation must export in the form of a table of functions (consisting of vfs_mount(), vfs_unmount(), vfs_sync() etc.). Each vfs contains a pointer that points to such a table corresponding to its own file system type. A "vnode" corresponds to a pathname (similar to an inode in unix ffs). Similar to vfs's, the set of operations permitted on vnodes also constitutes an interface which every file system implementation must export in the form of a table of functions (consisting of vn_open(), vn_close(), vn_mkdir() etc.). Each vnode contains a pointer that points to such a table corresponding to its own file system type. At run-time, different file systems behave more or less independantly. The only interaction between any two file systems arises because of "mount"ing, which impacts path name traversal routines as they have to switch from one vfs to another. The solution is elegantly described in the paper. Since file system calls are atomic, they need be serialized at the kernel level. Locking, however, is not done at the vnode level. It is left to the file system dependant layer. The overall design is pretty clean, re-entrant, object-oriented and does not degrade performance. Questions --------- Vnodes require that file system implementations export a common interface for vfs and vnode manipulation. Naturally, this would correspond to the lowest common denominator functionality offered by all file systems. Is this a disadvantage? Does it hinder innovation in file system design? Or do all file systems export more-or-less the same functionality?