Re: [9fans] Fossil; is the time right?

["Russ Cox" <rsc@plan9.bell-labs.com>]

cross@math.psu.edu:
> Okay, I'm going to be setting up a new file server for home in the next
> week or so.  What's the official recommendation at this point: Should I
> go with Fossil, or with the current fileserver?  Is Fossil considered
> stable enough?  Is the on-disk format likely to change a lot?  (Not a
> huge deal, but something that would necessitate inconvenient recoveries
> from venti.)  When does Bell Labs plan to become fossilized?  Thanks.

comparing pseudo-worm old fs with fossil is a
no-brainer -- use fossil.  if the on-disk format changes,
you only use snapshots not dumps.  the on-venti format
will not change.  hence all you have to do is reinitialize
your write buffer.  i've changed the on-disk format a handful
of times but never had to restart my file system.  you make
it sounds like ``recoveries from venti'' is a big deal.  it's not.
it's just a format command and then you're up and running again.
look at the wiki walkthrough -- it does one of these as
an example.

rog@vitanuova.com:
> it's been stable for me...  for all of two days, running it on my
> laptop :-).  it's survived lots of rebooting, and kernel crashing,
> with no probs, as advertised.

i've had similar experience, and i've been running it
since november.  the only time i lost a significant
amount of data was when i zeroed the first few
megabytes of the disk while trying to set up a second
fossil server elsewhere (oops).  and even that was
just old snapshots.

> it seems quite a lot slower than kfs (a naive measurement showed that
> it read 15MB 50% slower than kfs).  presumably this will change if
> it gets a read cache.

read performance is slow but not sluggish.  there's
a lot of room for improvement.  reads from the in-memory
cache are about the same speed as kfs.  if you give your
fossil more memory cache (the default is 1000 blocks, typically
8MB, and can be set with the -c option to open) it gets better.

kfs's reads from disk are obviously faster than fossil's reads
from venti.  a read cache will probably help there. 

> i have one query about its integrity: soft updates preserve the
> integrity of the write buffer; venti is log structured, and has no
> problem with being killed.
> 
> however, i wonder if it's possible to "lose" a block in between fossil
> and venti if one is running venti -w.  e.g.  fossil writes a block to
> venti, marks it as archived, reuses that block, and then the machine
> crashes before venti has got around to actually writing the block.
> 
> how does fossil guard against such an eventuality?

when running venti -w, there is a sync rpc that
doesn't return until all buffered blocks are on
disk.  fossil does not mark a block as archived
and does not update any pointers to that block
until it has synced to make sure the block is on disk.
i was very paranoid about this.

---

the main gotcha in the current fossil code is that
there is no warning when the write buffer is getting full,
and no easy way to check how much space is actually
used.  'fossil/flchk -f |[2] grep used' will do most of 
this but it's not convenient.  i need to make this better.