All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Neil Brown <neilb@suse.de>
Cc: Andre Noll <maan@systemlinux.org>,
	Dave Moon <p.b.w.tortilla@gmail.com>,
	linux-raid@vger.kernel.org
Subject: Re: How to avoid complete rebuild of RAID 6 array (6/8 active devices)
Date: Sun, 29 Jun 2008 17:58:30 -0400	[thread overview]
Message-ID: <48680586.609@tmr.com> (raw)
In-Reply-To: <18532.50062.63173.620773@notabene.brown>

Neil Brown wrote:
> On Wednesday June 25, maan@systemlinux.org wrote:
>   
>> On 15:37, Dave Moon wrote:
>>
>>     
>>> 1. If mdadm encounters a bit error during a RAID 6 rebuild, will it  
>>> just give up on that particular file and move on to recover other data  
>>> on the array? Or will it trash the entire array?
>>>       
>> The kernel will stop the array and give up.
>>     
>
> Not quite.  It will stop the recovery.  It won't stop the whole array
> though (I think...).
>
>   
>>> 2. Is it possible to cheat mdadm by somehow replacing the new "raid  
>>> metadata" on the 6 drives with the old data on the 2 drives? Will it  
>>> make mdadm think the array is clean, consistent and nothing ever  
>>> happened?
>>>       
>>> Please do note that I did not write ANY new data onto the RAID 6 array  
>>> from the time it was degraded until the time I brought it down with (-- 
>>> stop).
>>>       
>> Use --force, Luke. Man mdadm(8):
>>
>> 	-f, --force Assemble the array even if some superblocks
>> 	appear out-of-date
>>     
>
> --force only updates enough superblocks to assemble a working array.
> For raid6, that mean n-2 drives.  As there are n-2 drive, it won't try
> any harder.
>
> You best bet is to recreate the array with --assume-clean.
> Providing you have the chunksize, order of devices, etc the same, you
> should get your array back.
>   

Then what? What's going to happen when he does a check?

Of course build an array out of drives so unstable that you can't safelt 
*run* a check is another topic.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 



  reply	other threads:[~2008-06-29 21:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25  6:37 How to avoid complete rebuild of RAID 6 array (6/8 active devices) Dave Moon
2008-06-25 16:13 ` Andre Noll
2008-06-27 10:40   ` Neil Brown
2008-06-29 21:58     ` Bill Davidsen [this message]
2008-07-14 10:44       ` Matthias Urlichs
2008-07-14 16:14         ` David Greaves
2008-07-14 16:54           ` David Lethe
2008-07-14 22:58           ` Matthias Urlichs
2008-07-14 23:54             ` Richard Scobie
2008-07-15  0:05               ` Matthias Urlichs
2008-07-15 14:24             ` Keld Jørn Simonsen

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=48680586.609@tmr.com \
    --to=davidsen@tmr.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=maan@systemlinux.org \
    --cc=neilb@suse.de \
    --cc=p.b.w.tortilla@gmail.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.