approach on getting nullfs to work again

[Simon 'corecode' Schubert]

[original private post to matt, but something in my mail system must eat 
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 (=getting it work 
again), but in fact i have a hard time undestanding all that vfs and vnode 
and vx stuff...

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

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

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

I talked to joerg and we concluded that something seems to be missing in the 
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 
locked. once this works and the namecache won't resolve to an existing vnode, 
it can be created. 

now say /*/foo doesn't exist yet and there are two processes trying to create 
it. there is one problem: if processb wants to create /nullb/foo and processx 
wants to create /nullx/foo, both only lock /nullb/foo and /nullx/foo, 
respectively. both fail looking up an vnode and both are happy. but they 
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 
call it "shadow") parallel namecache entries, too, if they are being locked. 
Whereas this is not complicated to implement in cache_lock(), there is 
another problem: the namecache doesn't know about overlay filesystems. if 
doesn't know that there exist shadow namecache entries. so there must be some 
way of communication between namecache and vfs, maybe some 
vop_cache_create()?

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

-- 
/"\
\ /
 \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News
Attachment:
pgp00007.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 187 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20050208/cf2dc972/attachment-0019.obj>