From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <7c69fcec5a76332df147f744cebc9185@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 26 Jan 2009 08:42:05 -0500
To: 9fans@9fans.net
In-Reply-To: <1232951301.22808.105.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: 877a1052-ead4-11e9-9d60-3106f5b1d025

> > 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.

do you have any references to spontaenous data corruption
happening so soon on media that can be written elsewhere
without corruption?  ian ibm paper argus for raid[56] + chksum
that claimed that the p(lifetime) = 10^-13.

http://domino.watson.ibm.com/library/cyberdig.nsf/80741a79b3d5f4d085256b3600733b05/ca7b221ad09be77885257149004f7c53?OpenDocument&Highlight=0,RZ3652

but i didn't see any reason that this would apply to short-term
storage.

> 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.

if you're that worried, you do not need to modify fossil.
why don't you write a sdecc driver that as configuration
another sd device and a blocksize.  then you can just
add ecc on the way in and check it on the way out.

- erik