From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sun, 25 Jan 2009 22:28:21 -0800
From: "Roman V. Shaposhnik" <rvs@sun.com>
In-reply-to: <4ca84802efec71a6aa8363cf94ac0f58@quanstro.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-id: <1232951301.22808.105.camel@goose.sun.com>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <4ca84802efec71a6aa8363cf94ac0f58@quanstro.net>
Subject: Re: [9fans] Changelogs & Patches?
Topicbox-Message-UUID: 86f96e8e-ead4-11e9-9d60-3106f5b1d025

On Tue, 2009-01-20 at 21:02 -0500, erik quanstrom wrote:
> > 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.

Sure. But it must store the data *intact* long enough
for me to be able to do a snap. It has to be able to
at least warn me about data corruption.

> while corrupt data could end up in venti, the exposure lies only
> between snapshots.  you can rollback to the previous good
> score and continue.

That is my *entire* point. If fossil doesn't tell you that
the data in its buffer was/is corrupted -- you have no
reason to rollback.

Thanks,
Roman.