vfsx11.patch available - continuing vfs work (expert developers only)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    Another patch is ready for *limited* testing.  This one is intended for
    expert developers only.  It delves deeply into the VFS and that means
    anything can happen, including blown up filesystems.  What I need is
    primarily normal UFS filesystem and NFS client testing.

	fetch http://leaf.dragonflybsd.org/~dillon/vfsx11.patch

    Testing needed:

	UFS, CD9660, NFS client, Linux emulation.  *NOT* NFS server.

    Caveats:

	Coda is broken.  unionfs is broken.  nullfs is broken.  Probably
	other things as well.

	nfs serving mostly works, at least with DragonFly clients, but 
	there are some severe issues with ".." lookups that have not yet
	been resolved and the nfs server's use of fake namecache records
	for random vnode operations may cause normal operations on the 
	filesystem being served to fail in odd ways.  I am asking people
	NOT to test the NFS server yet.

	nfs client operations may fail to timeout cache records properly
	if changes are made directly on the server.

	There may be vnode and/or namecache leaks.

	Emulations may be broken to various degrees, possible corruption,
	etc etc.

    This patch adds all remaining NEW API calls to VFS, adds compatibility
    functions for VFSs that do not support the new calls (which is all of
    them at the moment), and changes most of the kernel over to using the
    new API calls.  In particular, the old namei()/lookup() API has finally
    been ripped out (yahhh)!!!  As in gone, poof, scrapped, nothing but a 
    smoking crater left.  The new nlookup() API is far less complex. 

    This is a major step forward in the VFS work, taking us well past the
    half-way mark.

    Still TODO:

    * The NFS server has to be fixed.  It needs to be able to reconstruct the
      namecache hierarchy when it is asked to lookup a random vnode.  At
      the moment it just creates a dummy namecache record for the vnode
      but without parent linkages this means that ".." lookups are broken.
      DragonFly clients are mostly insulated from the breakage since the
      namecache topology is usually present and thus the client is able to
      use a cached ".." instead of asking the server to look it up.

    * Some remaining cache purge's which break the namecache topology also
      need to be fixed, so the topology relinking code can finally be
      ripped out.

    * Unionfs and nullfs have to be rewritten.  No band-aids here, nothing
      short of a complete rewrite will work.  These VFS's use vnode-centric
      algorithms that simply will not work in the new scheme of things.
      they have to be rewritten to use namecache-centric algorithms.

    * NFS and UFS need native implementations of the new API functions.
      Right now they still implement just the old API functions and depend
      on the compatibility code to work.  This is particularly dangerous
      work for UFS where a mistake can lead to serious filesystem corruption.
      However, a rewrite should yield a major improvement in performance.

      I'm not sure what I am going to do about the other VFS's.  Maybe I'll
      maintain the compatibility code for them, at least for the foreseeable
      future.  Adding native new API support to all the VFSs in our tree
      would take a huge amount of time.  I haven't decided yet.

    * The new APIs provide wrapper functions in which journaling hooks can
      be laid.  It should be possible to begin working on high level
      journaling concepts.

    Again, I would appreciate testing just the basic UFS and NFS client 
    filesystems, and linux emulation, and only by expert developers.  It
    will help me stabilize the core of the new code.  Do not test NFS server
    operation.  unionfs and nullfs will not work at all so don't even try
    to use them.  This is *NOT* a prime-time patch.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>