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?