From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 22 Feb 2010 17:20:55 -0500
To: 9fans@9fans.net
Message-ID: <1971ab47ab615932bad737e1350bc893@ladd.quanstro.net>
In-Reply-To: <F6965774-9D71-45C1-9D09-841DB3071BF9@9srv.net>
References: <F6965774-9D71-45C1-9D09-841DB3071BF9@9srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] vtcache exhaustion
Topicbox-Message-UUID: d8951b3e-ead5-11e9-9d60-3106f5b1d025

> 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