On 2006-01-24, Csaba Henk <[EMAIL PROTECTED]> wrote: > On 2006-01-23, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: >> + renames on the lower layer don't trigger namecache >> renames/invalidations on a higher layer. [...] > It's easy to set up a scenario where the upper layer goes async with a > rename done in the lower one.
Just to give a concrete example: /tmp$ mkdir -p a/d a/dd b /tmp$ echo > a/d/x /tmp$ echo x > a/dd/x /tmp$ mount_null a b /tmp$ ls -l a/dd/x -rw-r--r-- 1 csaba wheel 2 Jan 24 01:17 a/dd/x /tmp$ ls -l b/dd/x -rw-r--r-- 1 csaba wheel 2 Jan 24 01:17 b/dd/x /tmp$ mv a/dd a/ddd /tmp$ mv a/d a/dd /tmp$ ls -l a/dd/x -rw-r--r-- 1 csaba wheel 0 Jan 24 01:17 a/dd/x /tmp$ ls -l b/dd/x -rw-r--r-- 1 csaba wheel 2 Jan 24 01:17 b/dd/x * * * OK, the neat idea of keeping references only downward seems to be unfeasible. Let's add a list of shadowing entries to the namecache struct. >From that on it seems to be easy: horizontal arrow deletions must be propagated into vertical direction. More concretely, cache_unlink_parent should iterate cache_shadow_detach() over the list of shadowing entries (as a tweak, there might be a flag which asks for not doing so). I think this would settle renaming issues. Similar mechanisms could be used to maintain groupwise namecache attibutes in each member of the shadow group, not just at the head. This way your greatest annoyances (including the API muck-up) could be solved. We could keep the locking mechanism as it is in my patch. That's transparent to the users anyway. What do you think? Csaba
