Re: [9fans] how to fix: 'arena arenas00 creation time after last write time'

[Russ Cox <rsc@swtch.com>]

> 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