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