All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Merry <bmerry@gmail.com>
To: Wols Lists <antlists@youngman.org.uk>
Cc: linux-raid@vger.kernel.org
Subject: Re: What to do about Offline_Uncorrectable and Pending_Sector in RAID1
Date: Mon, 14 Nov 2016 18:03:39 +0200	[thread overview]
Message-ID: <CAHy4j_5gROfjf42VwLxDfmdc6rKYdrWoBy6u2kDefx_Yzzn9kA@mail.gmail.com> (raw)
In-Reply-To: <5829DF1F.7030109@youngman.org.uk>

On 14 November 2016 at 17:58, Wols Lists <antlists@youngman.org.uk> wrote:
> On 14/11/16 15:52, Bruce Merry wrote:
>> On 13 November 2016 at 23:06, Wols Lists <antlists@youngman.org.uk> wrote:
>>> > Sounds like that drive could need replacing. I'd get a new drive and do
>>> > that as soon as possible - use the --replace option of mdadm - don't
>>> > fail the old drive and add the new.
>> Would you mind explaining why I should use --replace instead of taking
>> out the suspect drive? I guess I lose redundancy for any writes that
>> occur while the rebuild is happening, but I'd plan to do this with the
>> filesystem unmounted so there wouldn't be any writes.
>
> Because a replace will copy from the old drive to the new, recovering
> any failures from the rest of the array. A fail-and-add will have to
> rebuild the entire new array from what's left of the old, stressing the
> old array much more.

Okay, I can see how for RAID5 that might be a bad thing.

In my case however, it sounds like --replace will copy everything from
the failing drive, whereas I'd rather it copied everything from the
good drive. Same stress on the array, less chance of copying dodgy
data.

Bruce
-- 
Dr Bruce Merry
bmerry <@> gmail <.> com
http://www.brucemerry.org.za/
http://blog.brucemerry.org.za/

  reply	other threads:[~2016-11-14 16:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-13 18:46 What to do about Offline_Uncorrectable and Pending_Sector in RAID1 Bruce Merry
2016-11-13 20:18 ` Anthony Youngman
2016-11-13 20:51   ` Bruce Merry
2016-11-13 21:06     ` Wols Lists
2016-11-13 23:03       ` Phil Turmel
2016-11-14  6:50         ` Bruce Merry
2016-11-14 16:01           ` Phil Turmel
2016-11-14 16:09             ` Bruce Merry
2016-11-14 16:14               ` Phil Turmel
2016-11-14 15:52       ` Bruce Merry
2016-11-14 15:58         ` Wols Lists
2016-11-14 16:03           ` Bruce Merry [this message]
2016-11-14 16:09             ` Wols Lists
2016-11-14 16:10             ` Phil Turmel
2016-11-15 18:14           ` Peter Sangas
2016-11-15 18:49             ` Anthony Youngman
2016-11-15 19:22               ` Peter Sangas

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=CAHy4j_5gROfjf42VwLxDfmdc6rKYdrWoBy6u2kDefx_Yzzn9kA@mail.gmail.com \
    --to=bmerry@gmail.com \
    --cc=antlists@youngman.org.uk \
    --cc=linux-raid@vger.kernel.org \
    /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.