From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4ca84802efec71a6aa8363cf94ac0f58@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue, 20 Jan 2009 21:02:23 -0500
To: 9fans@9fans.net
In-Reply-To: <1232502224.11686.63.camel@goose.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Changelogs & Patches?
Topicbox-Message-UUID: 839d3888-ead4-11e9-9d60-3106f5b1d025

> > well, there's your problem.  you corrupted
> > the cache, not the venti store.  (you have no
> > venti store in this example.)
>
> I was specifically referring to a "normal operations"
> to conjure an image of a typical setup of fossil+venti.
>
> In such a setup a corrupted block from a fossil
> partition will go undetected and could end up
> being stored in venti. At that point it will become
> venti "problem".

it's important to keep in mind that fossil is just a write buffer.
it is not intended for the perminant storage of data.  while
corrupt data could end up in venti, the exposure lies only
between snapshots.  you can rollback to the previous good
score and continue.

ken's fs has a proper cache.  a corrupt cache can be recovered
from by dumping the cache and restarting from the last good
superblock.  in the days when the fs was really a worm stored
on mo disks, the worm was said to be very reliable storage.
with raid+scrubbing we try to overcome the limitations of
magnetic media.  while there isn't any block checksum, there is a
block tag.  tag checking has spotted a few instances of
corruption on my fs.  fs-level checksumming and encryption
is definately something i've considered.  actually, with tags
and encryption, checksumming is not necessary for error
detection.

- erik