> > # 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/
signature.asc
Description: This is a digitally signed message part
