From: Ben Bucksch <linux.news@bucksch.org>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: md dropping disks too early
Date: Wed, 17 Apr 2013 12:57:08 +0200 [thread overview]
Message-ID: <516E8004.8020103@bucksch.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1304170958500.23668@uplift.swm.pp.se>
Mikael Abrahamsson wrote, On 17.04.2013 10:00:
> Yes it does, but you need to do frequent scrubbing to reduce the risk
> of hitting this when you actually need it, ie after complete drive
> failure.
No, it's not "me" who needs to do that. The software needs to be set up
by default to do that, be it the kernel or some userland cron job from
the distro (advantage of latter: configurable). Apparently, Ubuntu 10.04
didn't do that.
Please stop blaming users, start blaming the software, and fix it.
> It's the combination of drive failure and other drive having read
> errors that RAID6 protects against. At least that's my primary use for
> it.
But a single read error is no reason to send the whole array to the
trash. RAID6 is merely a workaround here.
With joy, I read that this problem was described, recognized and
intended to be fixed by the developers:
http://neil.brown.name/blog/20110216044002#1 "Bad Block Log"
Unfortunately, that doesn't seem to be done, as I was running into
exactly that problem he describes. I hope somebody will fix that,
because he eloquently describes how the RAID achieves the opposite of
what it's intended to do.
Ben
next prev parent reply other threads:[~2013-04-17 10:57 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
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 ` Ben Bucksch [this message]
2013-04-17 15:03 ` md dropping disks too early 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=516E8004.8020103@bucksch.org \
--to=linux.news@bucksch.org \
--cc=linux-raid@vger.kernel.org \
--cc=swmike@swm.pp.se \
/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.