[9fans] Fossil; is the time right?

[9fans] Fossil; is the time right?

[Dan Cross]

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.

	- Dan C.

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

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 138 bytes --]

Our fossil seems pretty stable. We are using it as the `production'
file server. The old worm is out of duty (but kept hanging around).

[-- Attachment #2: Type: message/rfc822, Size: 1849 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] Fossil; is the time right?
Date: Fri, 14 Mar 2003 04:59:19 -0500
Message-ID: <200303140959.h2E9xJt09672@augusta.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.

	- Dan C.

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

[rob pike, esq.]

Go with fossil.  I installed one on January second and it hasn't
let me down yet.  You'll use less disk space and the snapshots
are nice, too.   You're probably not talking about optical disk
for the backup, but I'm used to that and the speed of the dump
makes a difference.

-rob

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

[Geoff Collyer]

In addition to `open -c' in fossil, you probably want to increase
venti's cache sizes; see -C, -I and -B.  The standalone file server
uses almost all of available memory for buffers, but fossil and venti
don't, you have to configure their memory use.

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

[Russ Cox]

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.

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

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 127 bytes --]

I never saw a tree flown away by a reboot.
IFAIK, that cannot happen, but I'm not the person to answer
that question. Sorry

[-- Attachment #2: Type: message/rfc822, Size: 1594 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Fossil; is the time right?
Date: Fri, 14 Mar 2003 15:10:54 0000
Message-ID: <df93997c67f86fc16026e2a9ca7eca1d@vitanuova.com>

> But I know that if I dont sync by hand using the console
> I loose some blocks (some of the last changes may be missing).

that's understandable.  at least in that case at least the directory
structure should remain intact.  (a sync for venti and for fossil that
blocked until all writes were complete would be helpful, i guess).

i was mostly concerned about the possibility that one might
potentially lose a whole tree if the block representing the root of
that tree was lost in transit.

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

[rog]

> But I know that if I dont sync by hand using the console
> I loose some blocks (some of the last changes may be missing).

that's understandable.  at least in that case at least the directory
structure should remain intact.  (a sync for venti and for fossil that
blocked until all writes were complete would be helpful, i guess).

i was mostly concerned about the possibility that one might
potentially lose a whole tree if the block representing the root of
that tree was lost in transit.

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

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

I don't know.
But I know that if I dont sync by hand using the console
I loose some blocks (some of the last changes may be missing).

I use this halt:

#!/bin/rc
while () {
	echo fsys main fync >>/srv/fscons
}

And wait until I see that for several calls there's no
dirty block.

Any better way?

[-- Attachment #2: Type: message/rfc822, Size: 1944 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Fossil; is the time right?
Date: Fri, 14 Mar 2003 13:39:50 0000
Message-ID: <bd1e305747386c4bc809c7aafcb2424d@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.

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.

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?

  cheers,
    rog.

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

[rog]

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.

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.

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?

  cheers,
    rog.