From: Ben Bucksch <linux.news@bucksch.org>
To: Robert L Mathews <lists@tigertech.com>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Use RAID-6!
Date: Wed, 17 Apr 2013 02:20:36 +0200 [thread overview]
Message-ID: <516DEAD4.7080305@bucksch.org> (raw)
In-Reply-To: <516DD433.50100@tigertech.com>
Robert L Mathews wrote, On 17.04.2013 00:44:
> the endless reports of complete array failures that appear on the list
> with RAID 5 and even RAID 6 (a recent topic, I note, was "multiple
> disk failures in an md raid6 array"). I almost never see anyone
> reporting complete loss of a RAID 1 array.
Correct
> The fundamental difference between RAID 1 and other levels seems to be
> that the usefulness of an individual array member doesn't rely on the
> state of any other member. This vastly reduces the impact of failures
> on the overall system. After using mdadm with various RAID levels
> since 2002 (thanks, Neil), I'm convinced that RAID 1 is by its very
> nature far less fragile than any other scheme. This belief is sadly
> reinforced almost every week by a new tale of woe on the mailing list.
Exactly.
However, I think the RAID5 problems are caused by bad design decisions
in the md implementation, not in the inherent concept of RAID5, though.
Many people seem to have problems getting to the data of their RAID5
array, although they have enough disks that are readable, but they can't
convince md to read it. RAID1 doesn't have that problem, because you can
ignore md when reading them. This is a home-made problem of Linux md.
FWIW, my own 10 years of experience with Linux md RAID led to the same
conclusion as you had.
See thread "md dropping disks too early"
Ben
next prev parent reply other threads:[~2013-04-17 0:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 16:44 Use RAID-6! Roy Sigurd Karlsbakk
2013-04-16 17:09 ` Mikael Abrahamsson
2013-04-16 17:25 ` Roy Sigurd Karlsbakk
2013-04-16 20:01 ` David Brown
2013-04-17 7:56 ` Mikael Abrahamsson
2013-04-17 9:26 ` David Brown
2013-04-16 19:52 ` Robert L Mathews
2013-04-16 20:05 ` Carsten Aulbert
2013-04-16 20:19 ` Roman Mamedov
2013-04-16 22:44 ` Robert L Mathews
2013-04-17 0:20 ` Ben Bucksch [this message]
2013-04-17 1:35 ` Adam Goryachev
2013-04-17 4:27 ` Robert L Mathews
2013-04-17 4:45 ` Adam Goryachev
2013-04-17 6:06 ` Stan Hoeppner
2013-04-17 11:13 ` Ben Bucksch
2013-04-17 11:32 ` Adam Goryachev
2013-04-17 11:51 ` Ben Bucksch
2013-04-17 17:50 ` Roy Sigurd Karlsbakk
2013-04-17 3:32 ` Robert L Mathews
2013-04-17 4:20 ` Roman Mamedov
2013-04-17 5:22 ` Robert L Mathews
2013-04-17 17:27 ` Roy Sigurd Karlsbakk
2013-04-16 23:42 ` md dropping disks too early (was: Use RAID-6!) Ben Bucksch
2013-04-17 8:00 ` Mikael Abrahamsson
2013-04-17 10:57 ` md dropping disks too early Ben Bucksch
2013-04-17 15:03 ` Keith Keller
2013-04-17 18:09 ` Roy Sigurd Karlsbakk
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=516DEAD4.7080305@bucksch.org \
--to=linux.news@bucksch.org \
--cc=linux-raid@vger.kernel.org \
--cc=lists@tigertech.com \
/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