From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <40B18127.3030807@chunder.com> Date: Mon, 24 May 2004 14:59:19 +1000 From: Bruce Ellis User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] fossil question References: <40B13E50.3010908@chunder.com> <40B179D9.9050601@chunder.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 85f10e9a-eacd-11e9-9e20-41e7f4b1d025 sorry, i read 'reasonable close' as 'reasonably close'. they are all ~0. Russ Cox wrote: > the idea is that each block has a start and end epoch. > start is the epoch it was created in, and end is the epoch > that it was unlinked from the tree. once the system has tossed > or archived the snapshots up through the close epoch, the block > can be reused. precise accounting isn't necessary as long as > the close epoch is correct. when a block isn't yet closed it has > a close epoch of ~0. that's why i asked. > > what does the epoch command print? maybe the epoch isn't > moving forward as it should. this can happen if a scan of the > file system turns up trees from earlier epochs. the epoch command > prints them out along with suggested clri messages that would > remove them. > > if the epoch command prints clris of /archive, it means the > archiver hasn't finished yet-- just wait. if it prints clris of old > /snapshot trees, run them and try epoch again. > > one more thing. fossil doesn't keep a precise accounting of > blocks that might have been made free by moving the epoch forward. > the df command rescans the disk to update the count if necessary. > that's why df is so slow. the original df didn't do this, but it's been > this way for more than a year. if you do not have a call to > cacheCountUsed inside fsysDf in 9fsys.c, then df is printing a > (perhaps gross) underestimate. > > russ > >