On Fri, May 11, 2007 at 04:21:13PM -0400, Greg Troxel wrote:
> Any progress on getting this fixed?  Apparently BSD systems need
> .. lookup to work, while linux systems shortcircuit this in the kernel.
> 
> pwd works in /coda, and fails in /coda/testserver.coda.cs.cmu.edu
> 
> poblano gdt 46 /coda/testserver.coda.cs.cmu.edu > l -ai
> ls: ..: No such file or directory
> total 11
>           4293914626 drwxr-xr-x  1 root  65534  2048 Jan 31  2006 .
>                 5817 drwxr-xr-x  1 7768  65534  2048 May 24  2006 15-610
>                76014 -rw-r--r--  1 7768  65534   896 Nov 19  2004 WELCOME
>                67617 drwxr-xr-x  1 root  65534  6144 May 11 11:40 playground

I've looked at it, but didn't see a reason why it wouldn't be working
right. There is a special case handling for '..' lookups where we do a
Get on the root's mountpoint to get the parent object.

Can you turn up venus debugging to 100 (vutil -d 100), run the failing
command and then vutil -stats which dumps the state of your cache into
the venus.log. I may be able to figure out from there why it isn't
working.

And yes, a problem for me is that the Linux kernel module doesn't need
venus to resolve '..' so I don't really get to see this problem (maybe
during repair, I had some trouble repairing a conflict in the root of a
realm the other day.

> oddly, in my own realm, ls -lai gives me a .. line:
> 
>  7 dr-xr-xr-x  1 root  65534  2048 May 11 14:15 ..
> 
> which matches my realm in /coda:
> 
> poblano gdt 55 /coda > l -ai
> total 7
>  7 dr-xr-xr-x   1 root  65534  2048 May 11 14:15 .
> 
> So it seems that .. is sort of in my kernel cache, but not really, and
> things aren't quite right.

It may be that the act of resolving the '..' lookup messes up the realm
mount point because it tries to update the name based on the lookup
i.e. it renames the realm to '..', which can then no longer resolve
because we rely on the name.

Jan