All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Guy Watkins <linux-raid@watkins-home.com>
Cc: 'Goswin von Brederlow' <goswin-v-b@web.de>, linux-raid@vger.kernel.org
Subject: Re: Requesting replace mode for changing a disk
Date: Sun, 10 May 2009 10:33:49 -0400	[thread overview]
Message-ID: <4A06E5CD.3020306@tmr.com> (raw)
In-Reply-To: <4019EAB86E8342028374C6968D6D67E2@m5>

Guy Watkins wrote:
> } -----Original Message-----
> } From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> } owner@vger.kernel.org] On Behalf Of Bill Davidsen
> } Sent: Saturday, May 09, 2009 7:08 PM
> } To: Goswin von Brederlow
> } Cc: linux-raid@vger.kernel.org
> } Subject: Re: Requesting replace mode for changing a disk
> } 
> } Goswin von Brederlow wrote:
> } > Hi,
> } >
> } > consider the following situation: You have a software raid that runs
> } > fine but one disk is suspect (e.g. SMART says failure imminent or
> } > something). How do you replace that disk?
> } >
> } > Currently you have do fail/remove the disk from the raid, add a
> } > fresh disk and resync. That leaves a large window in which redundancy
> } > is compromised. With current disk sizes that can be days.
> } >
> } > It would be nice if one could tell the kernel to replace a disk in a
> } > raid set with a spare without the need to degrade the raid.
> } >
> } > Thoughts?
> } >
> } 
> } This is one of many things proposed occasionally here, no real
> } objection, sometimes loud support, but no one actually *does* the code.
> } 
> } You have described the problem exactly, and the solution is still to do
> } it manually. But you don't need to fail the drive long term, if you can
> } stop the array for a few moments. You stop the array, remove the suspect
> } drive, create a raid1 of the suspect drive marked write-mostly and the
> } new spare, then add the raid1 in place of the suspect drive. For any
> } chunks present on the new drive the reads will go there, reducing
> } access, while data is copied from the old to the new in resync, and
> } writes still go to the old suspect drive so if the new drive fails you
> } are no worse off. When the raid1 is clean you stop the main array and
> } back the suspect drive out.
> } 
> } This is complicated enough that I totally agree a hot migrate would be
> } desirable. This is why people use lvm, although I make zero claims that
> } this same problem will solve more easily, I'm just not an lvm guru (or
> } even a newbie, just an occasional user).
>
> If the disk is suspect, I would expect read errors!
> If you have 1 bad block on the suspect disk, this process will fail.
>   

The raid1 is part of the original raid5, so the error should go to that 
level, where it will be recovered, and hopefully then rewritten. I have 
actually done this, and it has always completed, so I haven't researched 
why it worked, just noted that it did.
> If the logic was built-in to md, then any read errors while replacing could
> be recovered from another disk or disks.
>
>   


-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc

"You are disgraced professional losers. And by the way, give us our money back."
    - Representative Earl Pomeroy,  Democrat of North Dakota
on the A.I.G. executives who were paid bonuses  after a federal bailout.



  parent reply	other threads:[~2009-05-10 14:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-08 22:15 Requesting replace mode for changing a disk Goswin von Brederlow
2009-05-09 11:41 ` John Robinson
2009-05-09 23:07 ` Bill Davidsen
2009-05-10  1:22   ` Goswin von Brederlow
2009-05-10  2:20   ` Guy Watkins
2009-05-10  7:02     ` Goswin von Brederlow
2009-05-10 14:33     ` Bill Davidsen [this message]
2009-05-10 15:55       ` Guy Watkins
2009-05-13  1:21   ` Leslie Rhorer
2009-05-13  3:27     ` Goswin von Brederlow
2009-05-13  4:36       ` Neil Brown
2009-05-13  7:37         ` Goswin von Brederlow
2009-05-13 11:02           ` Neil Brown
2009-05-14 10:44         ` David Greaves
2009-05-14 12:00           ` Neil Brown
2009-05-13  4:31     ` Neil Brown
2009-05-13  4:37       ` SandeepKsinha
2009-05-13  4:54         ` Neil Brown
2009-05-13  5:07           ` SandeepKsinha
2009-05-13  5:21             ` NeilBrown
2009-05-13  5:31               ` SandeepKsinha
2009-05-13 10:51                 ` Neil Brown
2009-05-13  7:28       ` Goswin von Brederlow
2009-05-13  4:08 Sandeep K Sinha

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=4A06E5CD.3020306@tmr.com \
    --to=davidsen@tmr.com \
    --cc=goswin-v-b@web.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-raid@watkins-home.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.