On Thu, Jul 28, 2005 at 10:46:26AM -0600, Patrick Walsh wrote:
> On Thu, 2005-07-28 at 11:57 -0400, Jan Harkes wrote:
> > I don't know, does 'stat .' tell you that the linkcount is 1 or not? If
> > it is set to one, that is about as much as we can to to prevent the GNU
> > find optimization that I know of which is disabled by -noleaf.
> 
> 	Oddly, I'm not able to reproduce this today.
> 
> 	OK... just reproduced it by doing a:
>  
> cp -r /non-coda-path/to/source/dir/ /coda/realm/destdir
> 
> 	Then doing a find from the parent directory came up with no matches
> where a minute before it was finding some from a different directory.
> 
> 	The link counts are 1 or greater for each of the directories in
> question.

Interesting, I guess when we create the files, the kernel might not be
getting the stat/linkcount information from venus.

> 	Here's a transcript (with paths modified a little bit):
> 
> # cd /coda/realm/destdir
> # find . -name 'GetNew*'
> # find . -name 'GetNew*' -noleaf
> ./subdir/GetNewYYY.php
> ./subdir/GetNewZZZ.php
> ./orig/subdir/GetNewYYY.php
> ./orig/subdir/GetNewZZZ.php
> # stat .
>   File: "."
>   Size: 2048            Blocks: 4          IO Block:
> -4611713506218074112 Directory
> Device: ah/10d  Inode: 1352058954  Links: 2

This linkcount states that the directory has no subdirectories. So find
will consider everything a file.

You could do "cfs er .", which should tell venus to send an invalidation
call to the kernel. If you then run stat again it should show a
linkcount of 1 and the find should work again.

> # stat subdir
>   File: "subdir"
>   Size: 2048            Blocks: 4          IO Block:
> -4611694883239878656 Directory

Interesting IO Block values, not sure where those are coming from, I am
getting something like 8192 for the IO Block value, wonder why it isn't
4096, which is what the venus.cache filesystem is using.

Jan