approach on getting nullfs to work again

--nextPart2174255.eYCLhSi1KC
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

[original private post to matt, but something in my mail system must eat=20
mails, so i'm hoping that this one will get through]

hey dear hackers,

at the moment i'm having a stab at polishing up nullfs (=3Dgetting it work=
=20
again), but in fact i have a hard time undestanding all that vfs and vnode=
=20
and vx stuff...

what really troubles me is the new namecache hierarchy code. I don't know=20
about either the old namecache nor about your new code, so I might be total=
ly=20
off track here.

What happens if a file or directory in the underlying filesystem is being=20
renamed or deleted? Doesn't that mean that I need to adjust the namecache f=
or=20
the nullfs layer, too?

In case these parts of the nullfs were not cached yet, this is easy: do=20
nothing. But if those parts were resolved or even locked, what then? Is the=
re=20
a way to couple (wrap) namecache entries together like nullfs does with=20
vnodes?

I talked to joerg and we concluded that something seems to be missing in th=
e=20
namecache code. Imagine this situation:

/onefs (mountpoint, ufs)
  /foo (just a file, or not yet one. read below)
/nulla (mountpoint, plaintly covers /onefs)
  /foo (effectively the same file as /onefs/foo)
/nullb (mountpoint, covers /nulla)
  /foo (again, same file as /onefs/foo)
/nullx (mountpoint, covers /onefs)
  /foo (again this little file. all the same)

usually namecache entries get built up, linked to their parents and then=20
locked. once this works and the namecache won't resolve to an existing vnod=
e,=20
it can be created.=20

now say /*/foo doesn't exist yet and there are two processes trying to crea=
te=20
it. there is one problem: if processb wants to create /nullb/foo and proces=
sx=20
wants to create /nullx/foo, both only lock /nullb/foo and /nullx/foo,=20
respectively. both fail looking up an vnode and both are happy. but they=20
create the same file, /onefs/foo; collision. so the locking is wrong here.

We thought of a solution: overlay filesystems must lock their covered (i'll=
=20
call it "shadow") parallel namecache entries, too, if they are being locked=
=2E=20
Whereas this is not complicated to implement in cache_lock(), there is=20
another problem: the namecache doesn't know about overlay filesystems. if=20
doesn't know that there exist shadow namecache entries. so there must be so=
me=20
way of communication between namecache and vfs, maybe some=20
vop_cache_create()?

now this got a rather long mail, thanks for your attention
hoping for input,
  simon

=2D-=20
/"\
\ /
 \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News

--nextPart2174255.eYCLhSi1KC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQBCCUnur5S+dk6z85oRAtjOAJ0dGhri5JVc6GKTIAjNloDyMRBqaACfa0qh
W5lu2bOxKvvIjwNeb9XIexY=
=QHPT
-----END PGP SIGNATURE-----

--nextPart2174255.eYCLhSi1KC--