[OpenAFS] Re: getdcache oops
Mon, 25 Jul 2005 17:11:27 -0700
> Message: 4
> Date: Sun, 24 Jul 2005 23:44:14 -0400
> From: Chaskiel M Grundman <firstname.lastname@example.org>
> To: email@example.com
> Subject: Re: [OpenAFS] getdcache oops
> --On Sunday, July 24, 2005 07:20:07 PM -0700 Mike Polek <firstname.lastname@example.org>=20
>>getdcache<1>Unable to handle kernel paging request at virtual address
> this is osi_Panic("getdcache") which occurs when a process is unable to=20
> obtain free dcache slots after attempting (in a somewhat racy way) to=20
> obtain them for a period of 5 minutes.
Thanks!!! This is good information.
>> -memcache -blocks 65536 -chunksize 18
> This limits you to 256 (65536*1024 / 2^18) dcache entries
> How many processes do you have actively using afs concurrently?
Usually around 100. Been known to go up to 200.
> Can you switch to a disk cache?
I've considered it. I really like the idea of keeping the
speed of the memcache. The way our systems are structured,
disk cache seemed to slow things down. Our data basically
goes *through* the client. It's rarely accessed twice in the
same place, so having it sit it a disk cache shouldn't help
much. But having the extra disk I/O overhead was a problem
three years ago when we switched to memcache.
I'm considering using an in-memory disk cache by mounting
an ext2 fs on a file in a tmpfs filesystem via a loop device.
I'm guessing that would solve my problem, but it introduces
other problems and would require some time.
Anyway.... when I dropped the chunksize down to 16,
suddenly the errors changed to
Jul 24 19:05:27 servername kernel: afs: failed to store file (over quota)
So I'm guessing that it was a combo of quota filling up and
insufficient dcache entries. I'll keep the chunksize at 16
for the time being, and research an easy way to use the
disk cache manager in memory.