From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <200907282124.01673.corey@bitworthy.net> References: <4617.1248819296@lunacy.ugrad.cs.cmu.edu> <200907282124.01673.corey@bitworthy.net> Date: Wed, 29 Jul 2009 07:48:54 -0700 Message-ID: Subject: Re: [9fans] how to fix: 'arena arenas00 creation time after last write time' From: Russ Cox To: corey@bitworthy.net, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 31537ac8-ead5-11e9-9d60-3106f5b1d025 > The problem isn't confined to unnecessary warning messages > being printed. > > What about the 'arena arenas00: header is out-of-date' error, > and the subsequent re-indexing (on every reboot) which occurs > as a result of the condition? Despite the mention of "date" in the message, the logic behind that print is not time-sensitive. It's a different issue. How many clumps does it say it is indexing? How long does that take? It shouldn't be too long. Venti writes data blocks (clumps) to an append-only log. Then it does two more bookkeeping steps so it can find the data later. The first step is to update the block count in the arena header. The second step is to record an index entry for the block in the index disk and then update the indexed block count in the arena header. The data is committed once it is written to the log: the bookkeeping is just an optimization. The fact that you are getting the "out-of-date" print means that the first step has not happened for at least one block: venti looked ahead and found more data blocks than the header led it to expect. That's fine, it just means that venti was behind in its bookkeeping when you shut it down. (fshalt makes sure that the data is on disk; it doesn't wait around for the bookkeeping.) The next message you saw--indexing %d clumps--means that the second step hadn't happened for a perhaps larger number of blocks. Indexing here means loading information about the blocks into venti's in-memory cache, so that lookups for the blocks will succeed. If you leave the machine up long enough, venti will update the on-disk index slowly, in the background. If the pause at boot time due to this bookkeeping is bothering you, you can flush the current venti state to disk by running hget http://localhost:8000/flushdcache hget http://localhost:8000/flushicache # can take a while hget http://localhost:8000/flushdcache but replace localhost:8000 with your venti server's HTTP address (maybe that's the right one; I don't know). The fact that this is happening repeatedly suggests that fossil is trying to do a dump to venti but you are not leaving the machine up long enough that it can complete, so every time you reboot, it starts writing blocks to venti again, causing new indexing work that doesn't finish before you reboot again. If you want to end this cycle, the thing to do is let fossil finish its archive and let venti finish indexing it. If you run hget http://localhost:8000/storage one if the numbers is the total number of clumps written to the entire venti server. If you wait a minute and run it again and the number is growing, then fossil is writing to venti. Let it run until the number stops growing, and then wait for the venti flush above. > What I do know is that I'm having real and present issues with > venti, that are in some direct or indirect way related to at least > one or more of the following actors: > > bios/rtc clock > /env/timezone > /dev/rtc > aux/timesync Again, if you've commented out the "creation time" print, then your remaining issues are not clock-related. I think you're just rebooting more often than usual. Russ