From: Chris Mason <chris.mason@oracle.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Ahmed Kamal <email.ahmedkamal@googlemail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: single disk reed solomon codes
Date: Mon, 21 Jul 2008 09:05:43 -0400 [thread overview]
Message-ID: <1216645543.6932.101.camel@think.oraclecorp.com> (raw)
In-Reply-To: <1216486204.2475.11.camel@shinybook.infradead.org>
On Sat, 2008-07-19 at 09:50 -0700, David Woodhouse wrote:
> On Sat, 2008-07-19 at 15:21 +0300, Ahmed Kamal wrote:
> > Hi,
> > Since btrfs is someday going to be the default FS for Linux, and will
> > be on so many single disk PCs and laptops, I was thinking it should be
> > a good idea to insert some redundancy in single disk deployments. Of
> > course it can help with disk failures, since it's obviously a "single"
> > disk, but it can help with bit-rot, and with hardware sector read
> > errors. To get that we'd need to implement some kind of forward error
> > correction, possibly reed solomon code. I am not sure why no
> > filesystem seems to implement such scheme, although I believe at the
> > hardware level, such schemes are being used (so the idea is
> > applicable) ?
>
> We have implementations of such schemes in lib/reed_solomon/ in the
> kernel already.
>
> I'm quite interested in using btrfs on flash (I mean _real_ flash not
> SSDs where they have their own internal pseudo-fs pretending to be a
> disk). For that, we'd probably want to use precisely this kind of error
> correction. Although it's normal to do it at the block level rather than
> the filesystem object level;
>
The long term goal is to have the checksum algorithm selectable between
a number of choices. For metadata, you have 256 bits to use and for
data you can use anything that will fit in a btree block.
So, the way to do this for real flash would be to implement the
selectable checksum, and then store the sum + whatever error recovery
code you want in the checksum item.
-chris
prev parent reply other threads:[~2008-07-21 13:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-19 12:21 single disk reed solomon codes Ahmed Kamal
2008-07-19 15:18 ` Gerald Nowitzky
2008-07-19 22:15 ` Joe Peterson
2008-07-20 1:21 ` Bron Gondwana
2008-07-21 6:48 ` Tomasz Torcz
2008-07-21 7:40 ` Ahmed Kamal
2008-07-21 13:03 ` Chris Mason
2008-07-21 15:03 ` Dongjun Shin
2008-08-04 6:52 ` Ahmed Kamal
2008-08-04 11:31 ` Ric Wheeler
2008-07-19 16:50 ` David Woodhouse
2008-07-19 16:53 ` Ahmed Kamal
2008-07-21 13:05 ` Chris Mason [this message]
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=1216645543.6932.101.camel@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=dwmw2@infradead.org \
--cc=email.ahmedkamal@googlemail.com \
--cc=linux-btrfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.