From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3f9f8b75b4a7b780b3533cf218205cda@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu,  4 Jun 2009 15:25:47 -0400
To: 9fans@9fans.net
In-Reply-To: <42bc252f1ccd5b7887be54121d677cb6@terzarima.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] fossil
Topicbox-Message-UUID: 0466446e-ead5-11e9-9d60-3106f5b1d025

On Thu Jun  4 05:11:02 EDT 2009, forsyth@terzarima.net wrote:
> anyone else ever seen things like this from fossil? it seems a bit wayward...
>
> # on the fossil console, after `disk full' returned in errors:
>
> main: df
> 	main: 10,046,783,488 used + 35,180,756,598,784 free = 6,431,293,440 (156% used)
> main: snapclean 3600
> main: df
> 	main: 3,000,909,824 used + 3,430,383,616 free = 6,431,293,440 (46% used)

i suspect the free should be printed as a signed quanity. ☺

the management of fl->nused seems to permit a hole
(which isn't new) that could prevent fl->nused from being
decremented while still removing stuff from the fl in doRemoveLink.

perhaps i've misread the code.

it would be interesting to see what the difference between
the output of df would be if cacheCountUsed could be
asked to return both the cached fl->nused and also compute
it as it does if the epochs don't match.

it would be even more interesting if they differ, if resetting
fl->nused with the newly computed value just does the right
thing.

- erik