Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Wols Lists <antlists@youngman.org.uk>
To: Markus <M4rkusXXL@web.de>, linux-raid@vger.kernel.org
Subject: Re: future of raid 6
Date: Sun, 3 Sep 2017 22:03:14 +0100	[thread overview]
Message-ID: <59AC6E12.7050902@youngman.org.uk> (raw)
In-Reply-To: <2811558.CnJCJrJZ21@markus>

On 03/09/17 19:28, Markus wrote:
> Hello!
> 
> I have one question (maybe more) regarding the raid development. Especially 
> raid 6 and better.
> I read in some articles[1] that raid 6 will become worse as the size of the 
> disks grow but the (unrecoverable) error rate and data rate do not improve as 
> much. (Rebuilds are likely to hit an unrecoverable error, not to mention the 
> long time it will take to rebuild raids with +10TB per drive.)
> They estimated 2019 (that was written ten years ago).
> 
> Is there already something in progress for the md-raid in linux kernel?
> 	If so what and where?
> 	If not, why? Is it not needed yet? Is md-raid itself depreciated?
> 	What is the future for redundant mass storage?
> 
Hard errors aren't that common (at least until a drive fails :-)

A hard error is a sector that cannot be read. A soft error is one that
works fine after a reset (however you define said reset). A consumer
10TB disk can return one soft error per complete pass and still be
passed "it's good, it's within spec".

(And I think a lot of hard errors are down to not looking after the
data. Just as DRAM decays over nano-seconds, so do hard drives decay
over time, exacerbated by nearby writes. A hard error could simply be
data that's been degaussed by nearby writes. Fail to deal with that with
eg scrubs, and a perfectly functional drive can trash your data :-(

IFF someone thinks it's worth it, we may add raid-6+ functionality (ie
more than two parity drives), but I suspect enterprise drives will
simply become more reliable as they get bigger (manufacturers will move
more and more error correction technology into the firmware).

Bear in mind enterprise drives are roughly four binary orders of
magnitude more reliable, so a 160TB should just about read completely
without error.

As for "is md-raid deprecated", well a lot of the filesystem guys would
like to do so, and I sort of agree with them - the more layers of
abstraction, the worse things are. But the opposite also holds true -
put raid into the filesystem itself and the complexity there can explode
- just witness the trouble higher raid has caused the btrfs folks.

In *MY* humble (very) opinion, unrecoverable errors are far less common
than people think, technology is improving, and "2019" is a lot further
off than two years. That said, we will probably need something more than
plain raid-6 once we start using having disks in the 50-80TB range.
Unless, of course, technology inside the drive improves which it
probably will.

Cheers,
Wol


  reply	other threads:[~2017-09-03 21:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-03 18:28 future of raid 6 Markus
2017-09-03 21:03 ` Wols Lists [this message]
2017-09-03 21:53   ` Gandalf Corvotempesta
2017-09-04  9:53 ` Andreas Klauer
2017-09-04 12:28   ` Mikael Abrahamsson
2017-09-05  3:44   ` Phil Turmel

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=59AC6E12.7050902@youngman.org.uk \
    --to=antlists@youngman.org.uk \
    --cc=M4rkusXXL@web.de \
    --cc=linux-raid@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