linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Justin Ossevoort <justin@quarantainenet.nl>
To: Bart Noordervliet <bart@noordervliet.net>
Cc: Gordan Bobic <gordan@bobich.net>, linux-btrfs@vger.kernel.org
Subject: Re: Update to Project_ideas wiki page
Date: Thu, 18 Nov 2010 16:02:19 +0100	[thread overview]
Message-ID: <4CE53FFB.1050800@quarantainenet.nl> (raw)
In-Reply-To: <AANLkTinKX6uULbK88WdkXhH-XjUboUDf2FV8qopjZPcC@mail.gmail.com>

On 18/11/10 15:31, Bart Noordervliet wrote:
> On Wed, Nov 17, 2010 at 19:07, Gordan Bobic <gordan@bobich.net> wrote:
>> Since BTRFS is already doing some relatively radical things, I would like to
>> suggest that RAID5 and RAID6 be deemed obsolete. RAID5 isn't safely usable
>> for arrays bigger than about 5TB with disks that have a specified error rate
>> of 10^-14. RAID6 pushes that problem a little further away, but in the
>> longer term, I would argue that RAID (n+m) would work best. We specify that
>> of (n+m) disks in the array, we want n data disks and m redundancy disks. If
>> this is implemented in a generic way, then there won't be a need to
>> implement additional RAID modes later.
> 
> I presume you're talking about the uncaught read errors that makes
> many people avoid RAID5. Btrfs actually enables us to use it with
> confidence again, since using checksums it's able to detect these
> errors and prevent corruption of the array. So to the contrary, I see
> a lot of potential for parity-based redundancy in combination with
> btrfs.


No he's talking about the high chance of triggering another error during
the long time it takes to perform the recovery (and before your data is
redundant again). Often also attributed to multiple disks being from the
same batch and having the same flaws and lifetime expectancy.

But since btrfs would do this on a per object basis instead of the whole
array, only the objects whose blocks have gone are at risk (not
necessarily the whole filesystem). Furthermore, additional read errors
often only impact a subset of the files that were at risk.
Furthermore if recovery is half-way done when another error is triggerd
the already done part will still be available.

So the real strength is that corruptions are more likely only to impact
a small subset of the filesystem and that different objects can have
different amount of redundancy. So 'raid1' for metadata and other very
important files, no raid for unimportant data and raid5/6 for large
objects or for objects which only need a basic level of protection.

Regards,

    justin....

  reply	other threads:[~2010-11-18 15:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17  3:19 Update to Project_ideas wiki page Chris Ball
2010-11-17 14:31 ` Hugo Mills
2010-11-17 15:12   ` Bart Noordervliet
2010-11-17 17:19     ` Xavier Nicollet
2010-11-17 17:52     ` Mike Fedyk
2010-11-17 17:56     ` Hugo Mills
2010-11-17 18:07       ` Gordan Bobic
2010-11-17 18:41         ` Bart Kus
2010-11-18  8:36           ` Gordan Bobic
2010-11-18 14:31         ` Bart Noordervliet
2010-11-18 15:02           ` Justin Ossevoort [this message]
2010-11-18 15:06           ` Gordan Bobic
2010-11-17 18:14       ` Andreas Philipp
2010-11-17 18:34         ` Hugo Mills
2010-11-26 14:57   ` Paul Komkoff

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=4CE53FFB.1050800@quarantainenet.nl \
    --to=justin@quarantainenet.nl \
    --cc=bart@noordervliet.net \
    --cc=gordan@bobich.net \
    --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 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).