All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gordan Bobic <gordan@bobich.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Update to Project_ideas wiki page
Date: Thu, 18 Nov 2010 15:06:30 +0000	[thread overview]
Message-ID: <4CE540F6.7060701@bobich.net> (raw)
In-Reply-To: <AANLkTinKX6uULbK88WdkXhH-XjUboUDf2FV8qopjZPcC@mail.gmail.com>

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. What I'm talking about the the probability of finding an error 
during the process of rebuilding a degraded array. With a 6TB (usable) 
array and disks with 10^-14 error rate, the probability of getting an 
unrecoverable read error exceeds 50%. n+1 RAID isn't fit for use with 
the current generation of drives where n > 1-5TB depending on how 
important your data and downtime are and how good your backups are.

And I don't put much stock in the manufacturer figures, either, so 
assume that 10^-14 is optimistic of it is reported. On high capacity 
drives (especially 1TB Seagates, both 3 and 4 platter variants) I am 
certainly seeing a higher error rate than that on a significant fraction 
of the disks.

Gordan

  parent reply	other threads:[~2010-11-18 15:06 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
2010-11-18 15:06           ` Gordan Bobic [this message]
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=4CE540F6.7060701@bobich.net \
    --to=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 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.