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
