All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: John Stoffel <john@stoffel.org>
Cc: Robin Hill <robin@robinhill.me.uk>,
	Andreas Boman <aboman@midgaard.us>,
	linux-raid@vger.kernel.org, Benjamin ESTRABAUD <be@mpstor.com>
Subject: Re: Failed during rebuild (raid5)
Date: Fri, 03 May 2013 10:51:53 -0400	[thread overview]
Message-ID: <5183CF09.1080605@turmel.org> (raw)
In-Reply-To: <20867.49429.400548.184315@quad.stoffel.home>

On 05/03/2013 09:52 AM, John Stoffel wrote:
> 
> After watching endless threads about RAID5 arrays losing a disk, and
> then losing a second during the rebuild, I wonder if it would make
> sense to:
> 
> - have MD automatically increase all disk timeouts when doing a
>   rebuild.  The idea being that we are more tolerant of a bad sector
>   when rebuilding?  The idea would be to NOT just evict disks when in
>   potentially bad situations without trying really hard.  

This would be conterproductive for those users who actually follow
manufacturer guidelines when selecting drives for their arrays.

Anyways, it's a policy issue that belongs in userspace.  Distros can do
this today if they want.  There's no lack of scripts in this list's
archives.

> - Automatically setup an automatic scrub of the array that happens
>   weekly unless you explicitly turn it off.  This would possibly
>   require changes from the distros, but if it could be made a core
>   part of MD so that all the blocks in the array get read each week,
>   that would help with silent failures.

I understand some distros already do this.

> We've got all these compute cycles kicking around that could be used
> to make things even more reliable, we should be using them in some
> smart way.

But the "smart way" varies with the hardware at hand.  There's no "one
size fits all" solution here.

Phil


  reply	other threads:[~2013-05-03 14:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-03 11:23 Failed during rebuild (raid5) Andreas Boman
2013-05-03 11:38 ` Benjamin ESTRABAUD
2013-05-03 12:40   ` Robin Hill
2013-05-03 13:52     ` John Stoffel
2013-05-03 14:51       ` Phil Turmel [this message]
2013-05-03 16:23         ` John Stoffel
2013-05-03 16:32           ` Roman Mamedov
2013-05-04 14:48             ` maurice
2013-05-03 16:29       ` Mikael Abrahamsson
2013-05-03 19:29         ` John Stoffel
2013-05-04  4:14           ` Mikael Abrahamsson
2013-05-03 12:26 ` Ole Tange
2013-05-04 11:29   ` Andreas Boman
2013-05-05 14:00   ` Andreas Boman
2013-05-05 17:16     ` Andreas Boman
2013-05-06  1:10       ` Sam Bingner
2013-05-06  3:21       ` Phil Turmel
     [not found]         ` <51878BD0.9010809@midgaard.us>
2013-05-06 12:36           ` Phil Turmel
     [not found]             ` <5188189D.1060806@midgaard.us>
2013-05-07  0:39               ` Phil Turmel
2013-05-07  1:14                 ` Andreas Boman
2013-05-07  1:46                   ` Phil Turmel
2013-05-07  2:08                     ` Andreas Boman
2013-05-07  2:16                       ` Phil Turmel
2013-05-07  2:21                         ` Andreas Boman

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=5183CF09.1080605@turmel.org \
    --to=philip@turmel.org \
    --cc=aboman@midgaard.us \
    --cc=be@mpstor.com \
    --cc=john@stoffel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=robin@robinhill.me.uk \
    /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.