From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Brad Campbell <lists2009@fnarfbargle.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: raid 5 crashed
Date: Thu, 2 Jun 2016 07:52:11 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.02.1606020745490.28955@uplift.swm.pp.se> (raw)
In-Reply-To: <2f3e2fe6-1810-e7bd-7dc0-483ed4f0d46b@fnarfbargle.com>
On Thu, 2 Jun 2016, Brad Campbell wrote:
> People keep saying that. I've never encountered it. I suspect it's just not
Well, I have had drives that would occasionally throw a read error, but MD
requires that read error to happen three times before re-writing the
sector, and that never happened. See earlier discussions I had with Neil
on the topic. But you're correct, I don't see this on normally functioning
drives. Swapped out that drive (it didn't have any specific SMART errors
either) and everything was fine. I don't know what was wrong with it,
might have been something flying around in there causing spurious
problems.
> the problem that the hysterical ranting makes it out to be (either that or
> the pile of cheap and nasty drives I have here are model citizens).
> I've *never* seen a read error unless the drive was in trouble, and that
> includes running dd reads in a loop over multiple days continuously.
> If it were that bad I'd see drives failing SMART long tests routinely also,
> and that does not happen either.
I've seen enough read errors that I nowadays only run RAID6, never RAID5.
I'd also venture to say that considering the amount of people who come on
the list and who come on the #linux-raid IRC channel with "raid5,
one-drive-failed, and now I have read error on another drive so my array
doesn't resync, what should I do?", I'd say this is a real problem. It's
not however like "if you have a good drive, reading it 5 times will yield
a read error". The vendor bit error rate specification doesn't work like
that, so totally agree with you there.
--
Mikael Abrahamsson email: swmike@swm.pp.se
next prev parent reply other threads:[~2016-06-02 5:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-10 21:28 raid 5 crashed bobzer
2016-05-11 12:09 ` Mikael Abrahamsson
2016-05-11 13:15 ` Robin Hill
2016-05-26 3:06 ` bobzer
2016-05-27 19:19 ` bobzer
2016-05-30 15:01 ` bobzer
2016-05-30 19:04 ` Anthonys Lists
2016-05-30 22:00 ` bobzer
2016-05-31 13:45 ` Phil Turmel
2016-05-31 18:49 ` Wols Lists
2016-06-01 1:48 ` Brad Campbell
2016-06-01 3:46 ` Edward Kuns
2016-06-01 4:07 ` Brad Campbell
2016-06-01 5:23 ` Edward Kuns
2016-06-01 5:28 ` Brad Campbell
2016-06-01 15:36 ` Wols Lists
2016-06-01 23:15 ` Brad Campbell
2016-06-02 5:52 ` Mikael Abrahamsson [this message]
2016-06-02 14:01 ` Wols Lists
2016-06-02 15:27 ` Andreas Klauer
2016-06-03 1:05 ` Brad Campbell
2016-06-03 7:52 ` Mikael Abrahamsson
2016-06-03 15:27 ` bobzer
2016-06-03 16:31 ` Sarah Newman
2016-06-04 2:56 ` bobzer
2016-06-01 15:42 ` Wols Lists
2016-06-01 17:28 ` 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=alpine.DEB.2.02.1606020745490.28955@uplift.swm.pp.se \
--to=swmike@swm.pp.se \
--cc=linux-raid@vger.kernel.org \
--cc=lists2009@fnarfbargle.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 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.