All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.