> I've been running a vac-based backup on a few unix systems for a while
> now. A bit over a week ago, one of them started failing with this
> error:
>
> vac: vtcachelocal: asked for block #6289076; only 6288808
> blocks
>
[...]
>
> If a new cache block must be allocated... but the cache is
> filled...
> the
> library prints the score and reference count of every block in
> the
> cache
> and then aborts.
i mention this because it sounds so similar to a bug i found
in ken's fs. i hope this is useful, but it probablly isn't.
if you change an indirect block but not a direct
block, it's possible to miss dumping the direct block if that
block doesn't happen to be cached. this is because the test
was
from cw.c:/^isdirty
if(tag >= Tind1 && tag <= Tmaxind)
/* botch, get these modified */
if(s != Cnone)
return 1;
but i found that this is safer:
/*
* botch: we should mark the parents of modified
* indirect blocks as split-on-dump.
*/
if(tag >= Tind1 && tag <= Tmaxind)
return 2;
a better solution would be to do as the comment suggests.
i think that vac cache.c:/^lumpWalk makes the same sort
of determination about these lines (from the plan 9 version)
cache.c:623,626
if(0)fprint(2, "lumpWalk: %V:%s %d:%d-> %V:%d\n", u->score,
lumpState(u->state), u->type, offset, score, type);
v = cacheGetLump(c, score, type, size);
if(v == nil)
return nil;
- erik
