: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@backplane.com>