From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 24 May 2004 11:56:45 -0400 From: Russ Cox To: 9fans <9fans@cse.psu.edu> Subject: Re: [9fans] fossil question In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Topicbox-Message-UUID: 868ed95e-eacd-11e9-9e20-41e7f4b1d025 A couple people have sent me flchk outputs showing the leaks. They all look approximately like the ones I saw when I was working on fossil a year ago. I'm not sure where the leaked blocks come from. I can't seem to build a test script that produces leaked blocks reliably, and I've tried for quite a while. It could be that the leaks are from the disk not being completely synced when the machine is shut down -- since blocks are written out before the pointers to those blocks, if you shut down in between, you're going to leak some blocks. The best thing about fossil is snap -a. If it gets to the point where you've leaked away your entire disk (which seems to happen very slowly), record the snap, use vacfs to double-check that your data and dumps are there, and then run the bfree commands. The disk is just a write buffer, so as long as everything shows up in vacfs, you can't destroy anything important. If the worst happens (very unlikely) you can always flfmt with the snap -a score. Russ