| From: | "Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx> |
| Date: | Wed, 9 Feb 2005 00:23:19 +0100 |
[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
Description: PGP signature