Coda File System

Re: maximum cache size in venus

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Wed, 12 May 2004 01:36:45 -0400
On Tue, May 11, 2004 at 05:28:30PM -0700, Steve Simitzis wrote:
> On 05/10/04, Steve Simitzis <steve_at_saturn5.com> wrote: 
> > well, i'll continue my experiments then, to see how high i can raise
> > the cache without problems. i finally hit a crash at 1.9GB, unfortunately,
> > so my theory about a 2GB upper bound is now dead in the water. :)
> 
> well, it looks like i'm getting crashes at 250MB, too. so perhaps there is
> no practical upper bound for venus's cache.
> 
> a related question -
> 
> when venus dies, it will dump out its entire state, and first print out
> the object it crashed on.
> 
> example -
> 
> 0x6927fdc8 : fid = (65e7ba08.7f000008.788b6.41c7b), comp = , vol = 65e5f488
>         state = Normal, stat = { 18051, 1, 1082073484, 110, 0664, 1, File }, rc rights = 15
>         VV = {[ 2 0 0 0 0 0 0 0 ] [ 0xd5c 4034 ] [ 0 ]}
>         voltype = [0 1 0], fake = 0, fetching = 0 local = 0
>         rep = 1, data = 1, owrite = 0, dirty = 0, shadow = 0
>         mvstat = Normal
>         parent = (65e7ba08.7f000008.6b2b.1e519, 6a816788), children = 0
>         priority = 25000 (54072), hoard = [0, -2, 0], lastref = 70388424
>         mle_bindings = (0, 0), cleanstat = [-1, -1]
>         cachefile = [ 00/00/CF/40, 7291123, 18051/18051 ]
>         refs = [1 0 1], openers = [0 0 0]       lastresolved = 0

This is strange, the reference counts (refs) are tracking the internal
references [readers writers refcnt] and the open counts (openers) are
trying to follow the kernel references [reading writing executing]. It
seems strange that we have a readers refcount, but no filehandles open
for reading. I'll have to check the source to see where these counters
are manipulated.

> is it possible to translate this fid (65e7ba08.7f000008.788b6.41c7b)
> into a filename, or translate its parent into a filename? perhaps i
> could investigate this further by seeing if the files it's crashing on
> have anything in common.

If venus is running you can try,

    cfs getpath 7f000008.788b6.41c7b_at_your.realm.name

But that one gets the pathname information by taking the 'comp[onent] ='
part of the fso data and then iteratively doing the same for the parent.
However comp looks quite empty here so getpath probably won't give you
any useful information.

Jan
Received on 2004-05-12 01:39:27