Matt Dillon’s posted about the namecache work he plans to be doing now; his summary is included here.

userland vfs: The namecache needs to be disentangled from the VFS code else there would be a billion messages flying between userland and kernelland.

namespace locking: The intention is for the namecache to be used for namespace locking operations rather then having to hold an exclusive lock on the directory vnode. This will deserialize directory operations such as rm -rf and allow any precursor I/O for multiple create, rename, and other directory operations to proceed in parallel. The actual I/O operation on the directory will still need an exclusive lock, but we can potential do further optimizations

vnode locking simplification: VFS operations (VOP_* calls) have extremely convoluted vnode locking requirements, primarily due to the fact that the kernel depends on directory vnode locking to prevent unexpected namespace changes from taking place. VOP_RENAME() is especially bad. But if we do our namespace locking using the namecache, we can do away with exclusive directory locks during path lookups.

This also fixes the ‘race to root’ problem that NFS has (FreeBSD-5 fixed this by not locking the mount point directory), but this ALSO fixes filesystem chokepoints where a vnode lock can race up the directory chain and cause completely unrelated processes to stall, which FreeBSD-5 does not fix.