Re: [9fans] fossil question

[Russ Cox <russcox@gmail.com>]

> 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