Re: approach on getting nullfs to work again

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

On Wednesday, 9. February 2005 23:38, Matthew Dillon wrote:
>     When I designed the new namecache topology I considered the possibility
>     of having to deal with multiple overlayed filesystems and made the
>     vnode's v_namecache a list of namecache records instead of a pointer to
>     a single record.  The idea being that instead of having nullfs fake-up
>     vnodes (like it does in FreeBSD) we instead have it return the *actual*
>     vnode and only fake-up the namecache topology.  The system has no
> 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 * 
parameters just get passed through to the underlying filesystem and all vop 
calls that cope with struct namecache * need to wrap, grab the "real" 
namecache entry and pass it down?

>     For an operation being done directly on the underlying filesystem the
>     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 entry 
gets modified when being locked... i need to read the code again (and again 
and again)


>     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 
are able to reroute the vop calls so that we can shape up fake namecache 
entries, right?

thanks a lot for your input
  simon

-- 
/"\
\ /
 \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News

Attachment: pgp00011.pgp
Description: PGP signature