DragonFly kernel List (threaded) for 2005-02
Re: approach on getting nullfs to work again
:On Wed, Feb 09, 2005 at 09:38:15PM -0800, Matthew Dillon wrote:
:> :okay. this means all vop calls that don't work with struct namecache *=20
:> :parameters just get passed through to the underlying filesystem and all vop=
:> :calls that cope with struct namecache * need to wrap, grab the "real"=20
:> :namecache entry and pass it down?
:> VOP calls, yes. VFS calls (as Joerg indicates, fstatfs) might be a
:> different matter, but even there the best solution might actually be
:> a high level kernel solution ('gee this path is going through a nullfs
:> mount') rather then a low level VFS solution. It could be just a matter
:> of adding an ncp argument to the VFS op in question.
:What happens if we use the namecache entry in fp->f_data and follow that
:to the actual vnode before VOP calls? Even including a namecache entry
:directly in f_data and setting it to NULL for sockets?
This won't work because an active vnode will not always have a namecache
association. e.g. if you open() a file and then remove() the file.
This is why there is a separate f_ncp. A namecache pointer will not be
destroyed while a reference is held on it, and will not be invalidated
while held locked (except by the holder), but it can still be
invalidated at any other time and it's nc_vp vnode association *WILL* be
destroyed in that case. Furthermore, in the case of rename() and other
operations if you are e.g. renaming-over a target file, the namecache
pointer associated with the original target will be marked destroyed and
can *never* be reconstituted (at least not as an assocition with the
original target vnode which is no longer in the namespace).
So a namecache pointer is not a direct replacement for a vnode.
:> In fact, *ALL* VOP or VFS ops that specify a file path have the same
:> ability to distinguish between namespaces as VOP ops that pass namecache
:> pointers, because path ops will also have access to the related namecache
:Yeah, so we would want to convert the VFS calls to get a namecache entry
:as well. If we have that, I don't have any problems with using the vnodes
Possibly, yes. I would call that 'stage 2' or 'stage 3'.
ncp->nc_mount should be consistent now because, amoung other things,
all the VOP_*() compatibility macros are now getting the ops structure
via ncp->nc_mount->mnt_vn_use_ops. This means that a resolved and locked
namecache pointer can replace the use of a mount pointer in most VFS