vfs patch 04 (commit candidate)

[Matthew Dillon]

:Matthew Dillon wrote:
:>     Ok, here's an updated VFS patch.  I consider this a commit candidate. 
:>     This patch fixes a number of nullfs issues that came up from various
:>     people's testing.  The UFS code looks to be quite stable.
:
:Nullfs is well known to be broken on FreeBSD. Could you explain what are nullfs's 
:presently known limitations, at this point in the VFS work, and what allows nullfs to 
:work properly on DF?

    It should be possible to make it reliable, given enough people's bug
    reports along with associated kernel core dumps.  I have, unfortunately, 
    become rather an expert at that particular piece of spaghetti.

    The problem with nullfs in FreeBSD is simply a lack of maintainance.
    The VFS VOP_*() API is *very* complicated.  A lot of the secondary VFSs
    have severe hacks in them due to the authors not understanding the API.
    nullfs, for example, did not even come close to understanding either
    lookup()'s or rename()'s VOP semantics (and I'm still not sure I got it
    right).  I also found procfs to have severe issues... procfs was so bad
    that it wasn't even using real locking for VOP_LOCK() and VOP_UNLOCK().
    The patch fixes that too, though fixing it might result in more bugs 
    coming to light (but they at least ought to be easy to fix when they do).
    If my nullfs work pans out I'm sure someone will port it back to FreeBSD.

    Note however that I am going to have to rip up all the VFS's yet again
    in order to do the namespace locking.  The new work will significantly
    simplify the VOP semantics but it isn't going to be trivial.  Just about
    every directory vnode and many of the cnp's being passed to VOPs now
    are going to be replaced with namecache pointers.  If the FreeBSD folks
    wait too long nullfs's APIs will be so foreign that it won't be possible
    to port it back :-)

					    -Matt
					    Matthew Dillon 
					    <dillon at xxxxxxxxxxxxx>