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=
> :=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@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 12 之 15 篇)：