David Rosenthal, Evolving the Vnode Interface Problems with existing vnode: * The main problem with the existing vnode interface is that it doesn't evolve well. To ensure backwards compatability between future OS releases and current file system modules, almost half the vnode data structures are "reserved for future use." * A less major problem was the ease with which file system modules could be reused. (E.g., example is the quota-enabled file system). Design goals of new interface: * Design vnode interface to support versioning * vnodes should be stackable to reduce the effort to implement new file systems. Some design guidelines fall out of this: * Vnodes should be opaque (all vnodes should look the same, and expose no data to the upper levels of the OS). * Vnodes should be cheap (both because they have to be--we'll be using more of them since we're stacking them--and because they don't actually contain data) Some examples of how the stackable interface helps us: * No special case code for mount * can move Quota file system into it's own module, and implement it separate from the underlying file system. Similarly, we can implement caching, redirecting, semi-temporary, and other file system modules independent of the underlying file system on disk. Issues: * Locking: we need to be able to lock a vnode stack so that no one sees a malformed or partial stack while its being updated. The way this is currently implemented causes some performance drops. * Versioning: versioning is solved by having "version adapter" file systems, which sit on top of older vnode interfaces, and translate calls from the interface to calls in the old interface. This works well; in particular, it only charges a performance penalty on old file systems Overall: All together, this stackable vnode interface is very useful, and solves a bunch of important problems (versioning and the separation of modules into distinct Questions: * In network protocols, it can be useful to break the protocol layering (e.g., dropping superfluous TCP Acks over a slow wireless connection). Can you imagine a case where it might be useful (or even necessary) to do this with the vnode layering? * One of the major problems with the original interface was the overhead in preparing for future evolution. Is the memory footprint of the vnode implementation reduced with this new interface?