Re: approach on getting nullfs to work again

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

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=
> :=20
> :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?

>     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
>     pointer.

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
directly.

Joerg

> 
> :...
> :>     underlying filesystem is not aware of the overlay, but the namecache
> :>     code IS aware of the overlay because it sees multiple namecache
> :>     records attached to the vnode.  So the namecache code must scan
> :>     the list of namecache structures associated with the vnode and issue
> :>     the appropriate cache_inval*() calls on the namecache records other
> :>     then the one it was called with.
> :
> :on which cases would that be the case? i figure every time the namecache en=
> :try=20
> :gets modified when being locked... i need to read the code again (and again=
> :=20
> :and again)
> 
>     There are two major cases:
> 
>     * When a namecache entry is locked via nullfs we want to also lock
>       the underlying filesystem's namecache entry.  But as I said since
>       this involves an operation going through nullfs, and nullfs is aware
>       of the layering, then the nullfs code can be made responsible for
>       locks that fall into this category.
> 
>     * When a namecache entry is locked in the underlying filesystem, we 
>       also want to lock the related namecache entry in any overlays.
> 
>       Since the underlying filesystem is not aware of the overlays this
>       would have to be implemented within the namecache API (cache_lock
>       and friends).
> 
>       But I will stress that this does NOT have to be done in the initial
>       implementation.  Not having this does not prevent the rest of the 
>       work from going forward.
> 
>     This may require some additional pointers in the namecache structure so
>     the namecache API code can be made more explicitly aware of the layering.
> 
> :>     Questions?  Interest?  Simon, you want to code this up ?
> :
> :yep, sure. but i got the feeling that we in fact need fake vnodes, so that =
> :we=20
> :are able to reroute the vop calls so that we can shape up fake namecache=20
> :entries, right?
> :
> :thanks a lot for your input
> :  simon
> 
>     We should not need fake vnodes for nullfs.  We would need fake directory
>     vnodes for unionfs (to handle the merging).
> 
>     If it comes down to it and we need to make fstatfs() work on a file,
>     we can cache the ncp related to open file descriptors (we already cache
>     the ncp related to open directory descriptors so this would not be any
>     great leap).  I'm pretty confident that we can make it work because
>     most of the system already has access to the precise ncp (namecache
>     pointer) that was used to open a file or directory.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>