DragonFly commits List (threaded) for 2004-10
cvs commit: src/sys/kern src/sys/sys
dillon 2004/10/01 20:18:28 PDT
DragonFly src repository
sys/kern vfs_cache.c vfs_syscalls.c
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
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.
Revision Changes Path
1.31 +104 -4 src/sys/kern/vfs_cache.c
1.41 +1 -0 src/sys/kern/vfs_syscalls.c
1.11 +1 -0 src/sys/sys/namecache.h