[OpenAFS] Re: Problem with openafs-1.3.81 on kernel 2.6.11.7

[Dr A V Le Blanc]

On Thu 14 Apr 2005 at 10:46:47 -0400, Kris Van Hees <aedil-afs@alchar.org> wrote:
> I am almost willing to bet that the cache partition in this case is ext3 or
> any other jfs.

No, the cache partition is, and always was, ext2.

On Thu 14 Apr 2005 at 10:34:09 -0400, Chas Williams <chas@cmf.nrl.navy.mil> wrote:
> well it would be a good idea to mkfs the filesystem before you start
> 2.6/1.3.81 again just to make sure there are not residual bits.  however,
> i would guess that looks like truncate's arent happening in a timely
> fashion.  i believe someone else on the list has seen this behavior as
> well and might have a patch to make truncate() synchronize.
> 
> just curious, is there any chance you could try a memcache?  you wouldnt
> need a very big one.

I have now done a mkfs on the cache partition and rebooted.  I've also
made certain that both /etc/openafs/cacheinfo and the /etc/openafs/afs.conf
contain explicit cache limits; both say 300000, and the partition is
still a 500mb partition.  (Is this the right way to specify 300mb?
I can't find any use of the CACHE variable anywhere.)  I've then
rebooted the system and gone into afs and done a

     for i in `find . -type f -noleaf`;do cat $i >/dev/null;done

The cache partition quickly gets overfull and input/output errors
appear.  This looks like a real problem.  I am now using the
Debian packakes for 1.3.81, but previously I compiled openafs
from source and had the same problem, so it does not appear to
be specific to the Debian packages.

Is anyone else running 1.3.81 on 2.6.11 of some form, who is willing
to try the same test?

     -- Owen
     LeBlanc@mcc.ac.uk