[9fans] vtcache exhaustion

[Anthony Sorace <a@9srv.net>]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

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

Adding -v to the vac invocation, it seems to be failing in the same
place each
night. The last file listed is 12k, the next is 13k.

I'm running vac with -a to get the dump-like hierarchy. While the size
of my
current backup set is not much larger than the months of successful
runs, there
were a few days right before the failure when part of a large video
archive was
being accidentally included. The total backup size for those days was
about
10GB, but with low churn. The currently-failing backups have passed
the part
of the filesystem where that data is stored and have correctly omitted
it.

The last paragraph of venti-cache(3) (on p9p, although venti-cache(2)
reads
the same here) includes a few interesting statements. First:

	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.

This isn't happening; I get only the above "asked for" line. I don't
see in the
source anywhere this *ought* to be happening, either. Is the man page
simply
out of date? Was this pulled at some point? It seems like it'd be
helpful.

The same paragraph also notes:

	A full cache indicates either that the cache is too small, or, more
	commonly, that cache blocks are being leaked.

I've had a hard time tracking blocks through their local vs. global
states. Any
tips for tracking down any potential leaks? To get limping along
again, ought it
be safe to simply bump up the size of the cache in the vacfsopen call?

Anthony Sorace
Strand 1


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 201 bytes --]