Re: approach on getting nullfs to work again
:
:> problem with multiple namecache records referencing the same vnode. This
:> greatly reduces the burden on nullfs to translate VOP calls... it only has
:> to deal with namecache related translations, it does NOT have to deal with
:> things like VOP_READ(). The notion of the 'current' directory is now a
:> namecache record in DragonFly, so we can get away with this without
:> confusing someone CD'd into a nullfs filesystem. (In FreeBSD the 'current
:> directory' is a vnode and hence nullfs and unionfs had to fake-up the
:> vnode. In DragonFly it is a namecache pointer and we do NOT have to
:> fake-up the vnode).
:
: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.
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.
:...
:> 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>
討論串 (同標題文章)
完整討論串 (本文為第 10 之 15 篇)：