All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Molter <philip@corp.texas.net>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: linux-raid@vger.kernel.org
Subject: Re: Force parity resync on raid5?
Date: Tue, 10 Aug 2004 09:30:18 -0500	[thread overview]
Message-ID: <4118DBFA.6020607@corp.texas.net> (raw)
In-Reply-To: <16664.49686.253255.828936@cse.unsw.edu.au>

Neil Brown wrote:

> On Tuesday August 10, philip@corp.texas.net wrote:
> 
>>Linux RAID *has* to have sort of way to force a parity resync.  If it
>>doesn't have one, it needs one.  That's a glaring omission to make.
> 
> Well, you get what you pay for.....

Tell me where to send the checks.  Seriously.  I know you guys work hard 
on this stuff and I will gladly donate to the fund to have important (to 
me) features implemented.

> The easiest way to force a resync would be to re-create the array.
> 
>  - Note the exact order of the drives in the array, and the chunk size.
>  - Stop the array.
>  - Create the array with mdadm using --force.  That bit is important.

Do I need to note the parity algorithm, too?

>     mdadm --create /dev/mdX --level=5 --force --disks=whatever \
>        --chunksize=64k  /dev/sda1 /dev/sdb1 .....
> 
>  Remember the --force.  If you don't have it, you will get a recovery
>  cycle that rebuilds one drive against the others rather than a resync
>  that checks and corrects parity.
> 
>  This will recreate the array (almost) exactly as it currently is, but
>  it will not be marked 'clean', so a parity check-and-correct will
>  happen.

Does this destroy the data on the array?  I seem to remember getting 
this advice a while back when encountering a similar problem and seeing 
my data go up in smoke.  I could easily have done something wrong, though.

  reply	other threads:[~2004-08-10 14:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-10 12:03 Force parity resync on raid5? Philip Molter
2004-08-10 12:39 ` Neil Brown
2004-08-10 14:30   ` Philip Molter [this message]
2004-08-11  2:28     ` Neil Brown
2004-08-11  3:37       ` Philip Molter
2004-08-11  9:23       ` David Greaves
  -- strict thread matches above, loose matches on Subject: below --
2004-08-12 17:15 Salyzyn, Mark
2004-08-12 18:16 ` Guy
2004-08-09 23:10 Philip Molter
2004-08-10  9:04 ` Gordon Henderson
2004-08-12  4:06   ` Guy
2004-08-12 11:52     ` Philip Molter
2004-08-12 12:31     ` David Greaves
2004-08-12 15:22       ` Guy
2004-08-12 16:26         ` David Greaves
2004-08-12 17:07           ` Philip Molter

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=4118DBFA.6020607@corp.texas.net \
    --to=philip@corp.texas.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    /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.