:uhm thinking of that: if we fake up vnodes, we can't attach the namecache=20
:entries to the underlying vnode, because, well, the upper vnode needs the=20
:namecache entry already...
:
:while it would really be slick to do it without fake vnodes, i can't see=20
:how it could work. and with fake vnodes we need another link for the=20
:corresponding namecache entries.
My rewrite of the namecache was intended to allow the actual vnodes to
be used by nullfs and possibly other overlays.
The reason this works is because all namespace based VOP operations,
like rename, unlink, create, etc... these all pass a namecache pointer
to represent the namespace rather then a directory vnode. Processes
tracking open directories, current directory, root directory, etc...
they track the namecache pointer as well as the vnode. This means that
the system will not get confused if a vnode is represented by multiple
places in the namespace. At least theoretically.
For nullfs this should work. For something like unionfs we would probably
have to fake directory vnodes (but not file vnodes) in order to properly
merge the underlying directories.
The only area where I see some confusion might occur could be the
vnode's v_mount (pointing at the original filesystem mount point) verses
the nullfs mount, but if there is confusion there I guarentee that it
will be minor.
:maybe:
:
:/* in struct namecache: */
:struct namecache *nc_shadowgrp;
:
:/* Walk the circly linked group of shadowing namecache entries */
:sncp =3D ncp;
:while ((sncp =3D sncp->nc_shadowgrp) !=3D NULL && sncp !=3D ncp)
: /* invalidate or whatever */
:
:cheers
: simon
In actual fact, something like:
if (ncp->nc_vp) {
TAILQ_FOREACH(&ncp->nc_vp->v_namecache, scan, nc_entry) {
if (scan != ncp) {
... other namecache entries overloaded along with ncp ...
cache_inval(...)
}
}
}
It's slightly more complex then that, but that's the basic idea...
and the nice thing is that you don't have to get that part working
right off the bat. You can get all of the nullfs functionality
operational *BEFORE* you tackle the cache coherency issues.
-Matt
Matthew Dillon
<dillon@backplane.com>