(Illustration by Gaich Muramatsu)
> > # 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. How can you tell that? "Links: 2"? > 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. Yes, that is exactly what happened. But the IO Block remained the same. Actually, it didn't remain the same, but it's still not what you would expect. Here's an excerpt: # stat . File: "." Size: 2048 Blocks: 4 IO Block: -4611716804752957440 Directory Device: ah/10d Inode: 1352058954 Links: 2 ... # cfs er . # stat . File: "." Size: 2048 Blocks: 4 IO Block: -4611718454020399104 Directory Device: ah/10d Inode: 1352058954 Links: 1 Here are the values from venus.conf that aren't set to defaults: realm=abc cacheblocks=3145728 mapprivate=1 masquerade_port=2435 And in case it matters, here's server.conf's non-default values from one of the servers: rvm_log="/vice/RVMLOG" rvm_data="/vice/RVMDATA" rvm_data_length="524288000" ipaddress=x.x.x.x rvmtruncate=5 trace=100 allow_sha=1 Do you think the strange block size could indicate a problem or cause a problem at some point? Here's some other info, in case it helps: # df /coda Filesystem 1k-blocks Used Available Use% Mounted on coda 3145728 464 2937779 1% /coda # df /vicepa Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 40313996 1318908 36947204 4% /vicepa On second thought, this might not have anything at all to do with coda. So don't bother chasing it down. It's either a problem with stat or with our kernel, is my guess: # stat / File: "/" Size: 4096 Blocks: 8 IO Block: -4611715155485519872 Directory We're using the latest Redhat AS3 kernel. We're also using a RAID array, in case that has some impact. Anyway, I think the only problem here worth tracking down is why on a cp -r (and maybe other operations) the link count isn't being set properly... Thanks again for your help, Jan. ..Patrick -- Patrick Walsh eSoft Incorporated 303.444.1600 x3350 http://www.esoft.com/Received on 2005-07-28 14:26:23