VFS messaging/interfacing work stage 7b/99: More firming up of stage 7.
authorMatthew Dillon <dillon@dragonflybsd.org>
Sat, 2 Oct 2004 03:18:28 +0000 (03:18 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Sat, 2 Oct 2004 03:18:28 +0000 (03:18 +0000)
commit646a1cda625773b8739c4d519dca08e20b25efc7
tree87f2970d185710ad6de63ac02ce11bca657d4ccb
parent808cc7d066109ea72ffdabbd396189ac2b14e4ff
VFS messaging/interfacing work stage 7b/99: More firming up of stage 7.

(1) Enhance cache_resolve() to go up the directory chain as far as necessary
    to resolve the chain.  Previously I wimped out and returned an error.

(2) Be sure not to use the parent of a mount point to obtain the vnode
    operations vector for a child of a mount point (which resides on a
    different filesystem!).

Generally speaking the namecache directory chain should contain resolved
vnodes due to the fact that the vnode associated with a namecache entry is
held if any children exist, preventing the vnode from being recycled.
However, the NFS client code as originally written wimps out and does
wholesale namecache flushing of directories when it isn't sure about the
state of things (which is quite often, especially when you are rm'ing
files), and this breaks that assumption and causes some intermediate NFS
directory nodes to revert back into an 'unresolved' state.  This will
eventually be fixed, but not right now.

Add a nc_mount pointer to the namecache structure.  For the moment this is
only used to get at the mount point associated with a NCF_MOUNTPT namecache
node (whether resolved or unresolved), making it easier for us to resolve
the vnode.  But eventually it will be used as the basis for obtaining the
v_ops for (new stlye) VOP calls on an unresolved namecache node, saving us
a few indirections so I don't consider it a hack.

Bugs-and-cores-by: drhodus
sys/kern/vfs_cache.c
sys/kern/vfs_syscalls.c
sys/sys/namecache.h