From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 24 May 2004 00:47:50 -0400 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] fossil question In-Reply-To: <40B179D9.9050601@chunder.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <40B13E50.3010908@chunder.com> <40B179D9.9050601@chunder.com> Topicbox-Message-UUID: 85eb089c-eacd-11e9-9e20-41e7f4b1d025 > no, the epochs seem random (777, 1083, etc) - the current > epoch is 3442. the first N blocks are all unreachable > and then it starts thinning out. they should be (somewhat) random. as long as they're not ~0. if the close number is less than the epoch, they should be automatically found and freed. 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