vfs05.patch

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    This is what is tentitively going in tomorrow (thursday).  It looks
    like a can of worms but half of it is stuff to glue the old and new
    interfaces together so I can convert things piecemeal, then I get to
    scrape all the glue off and hopefully have a work of art :-).  In
    fact, this first patch only moves [f]chdir(), [l]stat(), and the mount
    code over to the new interface.

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

    Basically, for those people interested, the old BSD API worked like
    this:

    [setup path] -> namei -> elm -> VOP_LOOKUP -> [side effects] -> vfs_cache
							|
							V
						    cache coherency
						 [implemented per vfs basis]

    [all sorts of locked vnodes directory vnodes, etc] -> VOP_*() ->
							[weird side effects]

    And the new API works like this:

    [setup path] -> nlookup -> vfs_cache -> [miss] -> VOP_RESOLVE ->
				  |			[just fills in a
				  V			passed namecache 
		    high level cache coherency 		structure, no other
			policy hooks			side effects].

    [fewer locked namecache structures] -> VOP_*() -> [no side effects]

    That is, the new interface does all the path handling in the kernel 
    without touching the VFS, and only talks to the VFS when it needs to 
    resolve a file/dir name that it doesn't have a namecache record for. 
    And then instead of passing all sorts of weird combinations of vnodes 
    and directory vnodes and cnp's (componentname structures) in a multitude
    of lock/not-locked configurations the new interface simply passes
    namecache records to those other VOPs that deal with namespace operations
    (e.g. stat, remove, create, rename) and the VFS code can pull out
    whatever vnodes it needs from the namecache records.

    Seems simple enough, except the old API has all sorts of interdependancies
    between VOP_LOOKUP() and VOP_REMOVE/RENAME/CREATE which the new much
    simplified VOP_RESOLVE interface isn't supposed to handle, so all of that
    junk has to be moved into VOP_REMOVE/RENAME/CREATE for each VFS in the
    system, and *that* is a lot of work.

    But the grand result, when all is said and done, is going to be a big
    improvement in path lookup performance (at least 2x), much less vnode
    lock contention, a caching layer that resides entirely in a high
    level kernel layer that we can then implement a separately managed cache
    coherency policy for, no kernel requirement to hold directory vnodes
    locked through namespace operations (though most VFS's will still do
    that themselves until they can be fixed), and a hugely simplified
    VFS API which will it a lot easier to write new filesystems and, of
    course, make it easier for us to implement a user process messaging
    API to run VFS's in userspace.

    --

    So, prepare for a bit of instability the next few weeks!  The worst
    should be over in ~3 weeks.  If you want your DragonFly to remain
    totally stable then stick with the "DragonFly_Stable" tag instead of head.
    If you want to test the VFS work as it goes in, stick with head.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>