Re: approach on getting nullfs to work again
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
討論串 (同標題文章)
完整討論串 (本文為第 2 之 15 篇)：