vfsx11.patch available - continuing vfs work (expert developers
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@backplane.com>