Re: approach on getting nullfs to work again

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
:> 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@xxxxxxxxxxxxx>