Re: [9fans] vtcache exhaustion

[erik quanstrom <quanstro@quanstro.net>]

> 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