approach on getting nullfs to work again

[Devon H. O'Dell]

On Wed, 2005-02-09 at 00:23 +0100, Simon 'corecode' Schubert wrote:
> [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

I've no idea. Why don't you ask Matt? :-D

/me hides.

--Devon