On Sat, Sep 22, 2007 at 09:57:25AM -0400, Greg Troxel wrote:
>   So the explicit lookup for the non-existing testvol name ended up
>   populating the kernel cache with a negative dentry. This negative entry
>   isn't dropped once the mountpoint is created, but I can get it to work
>   when I force an upcall which tells the kernel to flush the parent
>   directory and it's children,
> 
> You might need to take out your 'cache consistency is hard!' barbie doll!
>
> Seriously, this is hard, and it would be good to document the cache
> invariants explicitly so that it can be checked that they are maintained
> on all state transitions.  It might also be cool to have a debug option
> in the kernel to walk the cache, do an upcall for each to get status,
> and compare.

Last time I checked only Linux had a directory/name cache, so this is
terribly OS specific. Also the directory cache is provided by the VFS
and it is shared by all file systems, it would be pretty hard/impossible
to just walk the Coda related entries. It also doesn't cache attributes,
just the mapping from names to objects and in some cases from names to
the non-existance of objects, attributes are cached by the inode cache.

But over all, dealing with the caches isn't all that hard. Creating a
new mountpoint is different from the typical mkdir/link/creat operations
because it is passed to venus as an ioctl and doesn't get handled by the
VFS which is why the negative dentry didn't get dropped. The simplest
way to deal with it is to pretend the object was created by some other
client and we just received a callback on the parent directory.

Jan