--nextPart2204539.OWKgLNB8Zk
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday, 9. February 2005 23:38, Matthew Dillon wrote:
> When I designed the new namecache topology I considered the possibili=
ty
> 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 *actua=
l*
> 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 *=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?
> 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 en=
try=20
gets modified when being locked... i need to read the code again (and again=
=20
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=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
=2D-=20
/"\
\ /
\ ASCII Ribbon Campaign
/ \ Against HTML Mail and News
--nextPart2204539.OWKgLNB8Zk
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)
iD8DBQBCCpuBr5S+dk6z85oRAklRAJkB0Sij2kknID9CzOehJyJ+lWMCmQCdHwD7
5IW9ayONT3qLyasH1zhzR7I=
=9EKI
-----END PGP SIGNATURE-----
--nextPart2204539.OWKgLNB8Zk--