From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] Changelogs & Patches?
Date: Mon, 26 Jan 2009 08:42:05 -0500 [thread overview]
Message-ID: <7c69fcec5a76332df147f744cebc9185@quanstro.net> (raw)
In-Reply-To: <1232951301.22808.105.camel@goose.sun.com>
> > 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
next prev parent reply other threads:[~2009-01-26 13:42 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-22 15:27 Venkatesh Srinivas
2008-12-22 15:29 ` erik quanstrom
2008-12-22 16:41 ` Charles Forsyth
2008-12-25 6:34 ` Roman Shaposhnik
2008-12-25 6:40 ` erik quanstrom
2008-12-26 4:28 ` Roman Shaposhnik
2008-12-26 4:45 ` lucio
2008-12-26 4:57 ` Anthony Sorace
2008-12-26 6:19 ` blstuart
2008-12-27 8:00 ` Roman Shaposhnik
2008-12-27 11:56 ` erik quanstrom
2008-12-30 0:31 ` Roman Shaposhnik
2008-12-30 0:57 ` erik quanstrom
2009-01-05 5:19 ` Roman V. Shaposhnik
2009-01-05 5:28 ` erik quanstrom
2008-12-22 17:03 ` Devon H. O'Dell
2008-12-23 4:31 ` Uriel
2008-12-23 4:46 ` Nathaniel W Filardo
2008-12-25 6:50 ` Roman Shaposhnik
2008-12-25 14:37 ` erik quanstrom
2008-12-26 13:27 ` Charles Forsyth
2008-12-26 13:33 ` Charles Forsyth
2008-12-26 14:27 ` tlaronde
2008-12-26 17:25 ` blstuart
2008-12-26 18:14 ` tlaronde
2008-12-26 18:20 ` erik quanstrom
2008-12-26 18:52 ` tlaronde
2008-12-26 21:44 ` blstuart
2008-12-26 22:04 ` Eris Discordia
2008-12-26 22:30 ` erik quanstrom
2008-12-26 23:00 ` blstuart
2008-12-27 6:04 ` Eris Discordia
2008-12-27 10:36 ` tlaronde
2008-12-27 16:27 ` Eris Discordia
2008-12-29 23:54 ` Roman Shaposhnik
2008-12-30 0:13 ` hiro
2008-12-30 1:07 ` erik quanstrom
2008-12-30 1:48 ` Charles Forsyth
2008-12-30 13:18 ` Uriel
2008-12-30 15:06 ` C H Forsyth
2008-12-30 17:31 ` Uriel
2008-12-31 1:58 ` Noah Evans
2009-01-03 22:03 ` sqweek
2009-01-05 5:05 ` Roman V. Shaposhnik
2009-01-05 5:12 ` erik quanstrom
2009-01-06 5:06 ` Roman Shaposhnik
2009-01-06 13:55 ` erik quanstrom
2009-01-05 5:24 ` andrey mirtchovski
2009-01-06 5:49 ` Roman Shaposhnik
2009-01-06 14:22 ` andrey mirtchovski
2009-01-06 16:19 ` erik quanstrom
2009-01-06 23:23 ` Roman V. Shaposhnik
2009-01-06 23:44 ` erik quanstrom
2009-01-08 0:36 ` Roman V. Shaposhnik
2009-01-08 1:11 ` erik quanstrom
2009-01-20 6:20 ` Roman Shaposhnik
2009-01-20 14:19 ` erik quanstrom
2009-01-20 22:30 ` Roman V. Shaposhnik
2009-01-20 23:36 ` erik quanstrom
2009-01-21 1:43 ` Roman V. Shaposhnik
2009-01-21 2:02 ` erik quanstrom
2009-01-26 6:28 ` Roman V. Shaposhnik
2009-01-26 13:42 ` erik quanstrom [this message]
2009-01-26 16:15 ` Roman V. Shaposhnik
2009-01-26 16:39 ` erik quanstrom
2009-01-27 4:45 ` Roman Shaposhnik
2009-01-21 19:02 ` Uriel
2009-01-21 19:53 ` Steve Simon
2009-01-24 3:15 ` Roman V. Shaposhnik
2009-01-24 3:36 ` erik quanstrom
2009-01-26 6:21 ` Roman V. Shaposhnik
2009-01-26 13:53 ` erik quanstrom
2009-01-26 16:21 ` Roman V. Shaposhnik
2009-01-26 17:37 ` erik quanstrom
2009-01-27 4:51 ` Roman Shaposhnik
2009-01-27 5:44 ` erik quanstrom
2009-01-21 20:01 ` erik quanstrom
2009-01-24 3:19 ` Roman V. Shaposhnik
2009-01-24 3:25 ` erik quanstrom
2009-01-20 6:48 ` Roman Shaposhnik
2009-01-20 14:13 ` erik quanstrom
2009-01-20 16:19 ` Steve Simon
2009-01-20 23:52 ` andrey mirtchovski
2009-01-21 4:49 ` Dave Eckhardt
2009-01-21 6:38 ` Steve Simon
2009-01-21 14:02 ` erik quanstrom
2009-01-26 6:16 ` Roman V. Shaposhnik
2009-01-26 16:22 ` Russ Cox
2009-01-26 19:42 ` Roman V. Shaposhnik
2009-01-26 20:11 ` Steve Simon
2008-12-27 7:40 ` Roman Shaposhnik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c69fcec5a76332df147f744cebc9185@quanstro.net \
--to=quanstro@quanstro.net \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).