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