RAID rebuild on Create

RAID rebuild on Create

[Jan Engelhardt]

Hi list,


when a user does `mdadm -C /dev/md0 -l <any> -n <whatever fits> 
<devices>`, the array gets rebuilt for at least RAID1 and RAID5, even if 
the disk contents are most likely not of importance (otherwise we would 
not be creating a raid array right now). Could not this needless resync 
be skipped - what do you think?


Jan
-- 

Re: RAID rebuild on Create

[Dan Williams]

On 4/30/07, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> Hi list,
>
>
> when a user does `mdadm -C /dev/md0 -l <any> -n <whatever fits>
> <devices>`, the array gets rebuilt for at least RAID1 and RAID5, even if
> the disk contents are most likely not of importance (otherwise we would
> not be creating a raid array right now). Could not this needless resync
> be skipped - what do you think?
>
If you want his behavior you can always create the array with a
'missing' device to hold off the resync process.  Otherwise, if all
disks are available, why not let the array make forward progress to a
protected state?

Also, the resync thread automatically yields to new data coming into
the array, so you can effectively sync an array by writing to all the
blocks.

>
> Jan

--
Dan

Re: RAID rebuild on Create

[Jan Engelhardt]

On Apr 30 2007 11:19, Dan Williams wrote:
>> 
>> when a user does `mdadm -C /dev/md0 -l <any> -n <whatever fits>
>> <devices>`, the array gets rebuilt for at least RAID1 and RAID5, even if
>> the disk contents are most likely not of importance (otherwise we would
>> not be creating a raid array right now). Could not this needless resync
>> be skipped - what do you think?
>
> If you want his behavior you can always create the array with a
> 'missing' device to hold off the resync process.  Otherwise, if all
> disks are available, why not let the array make forward progress to a
> protected state?

Having a device missing in the array does not create a protected state
as you call it. What I was out at - can't the array wait with syncing
blocks until I have actually written something there for the first
time? This should not impact protection.

_Especially_ if one starts out with blank disks. Then the resync
process copies zeroes to zeroes (before we even run mkfs). And it
chews a bit on PCI bandwidth.

> Also, the resync thread automatically yields to new data coming into
> the array, so you can effectively sync an array by writing to all the
> blocks.


Jan
-- 

RE: RAID rebuild on Create

[Patrick_Boyd]

But then the array needs to keep track of where data is so that it knows
what is "good" and what is "bad." Instead it takes the array to a known
good state to start out with and you don't have to start out with blank
disks. 

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Jan Engelhardt
Sent: Monday, April 30, 2007 1:35 PM
To: Dan Williams
Cc: linux-raid@vger.kernel.org
Subject: Re: RAID rebuild on Create


On Apr 30 2007 11:19, Dan Williams wrote:
>> 
>> when a user does `mdadm -C /dev/md0 -l <any> -n <whatever fits>
>> <devices>`, the array gets rebuilt for at least RAID1 and RAID5, even
if
>> the disk contents are most likely not of importance (otherwise we
would
>> not be creating a raid array right now). Could not this needless
resync
>> be skipped - what do you think?
>
> If you want his behavior you can always create the array with a
> 'missing' device to hold off the resync process.  Otherwise, if all
> disks are available, why not let the array make forward progress to a
> protected state?

Having a device missing in the array does not create a protected state
as you call it. What I was out at - can't the array wait with syncing
blocks until I have actually written something there for the first
time? This should not impact protection.

_Especially_ if one starts out with blank disks. Then the resync
process copies zeroes to zeroes (before we even run mkfs). And it
chews a bit on PCI bandwidth.

> Also, the resync thread automatically yields to new data coming into
> the array, so you can effectively sync an array by writing to all the
> blocks.


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: RAID rebuild on Create

[Jan Engelhardt]

On Apr 30 2007 13:54, Patrick_Boyd@Dell.com wrote:
>
>But then the array needs to keep track of where data is so that it knows
>what is "good" and what is "bad."

I assume it knows that, because you can reboot while an array is still
syncing and it Does The Right Thing. Furthermore, there is also the
relatively new mdadm -b option.

>Instead it takes the array to a known
>good state to start out with and you don't have to start out with blank
>disks. 

Jan
-- 

Re: RAID rebuild on Create

[David Greaves]

Jan Engelhardt wrote:
> Hi list,
> 
> 
> when a user does `mdadm -C /dev/md0 -l <any> -n <whatever fits> 
> <devices>`, the array gets rebuilt for at least RAID1 and RAID5, even if 
> the disk contents are most likely not of importance (otherwise we would 
> not be creating a raid array right now). Could not this needless resync 
> be skipped - what do you think?
> 
> 
> Jan

This is an FAQ - and I'll put it there RSN :)

Here's one answer from Neil from the archives (google "avoiding the initial
resync on --create"):

Otherwise I agree.  There is no real need to perform the sync of a
raid1 at creation.
However it seems to be a good idea to regularly 'check' an array to
make sure that all blocks on all disks get read to find sleeping bad
blocks early.  If you didn't sync first, then every check will find
lots of errors.  Ofcourse you could 'repair' instead of 'check'.  Or
do that once.  Or something.

For raid6 it is also safe to not sync first, though with the same
caveat as raid1.  Raid6 always updates parity by reading all blocks in
the stripe that aren't known and calculating P and Q.  So the first
write to a stripe will make P and Q correct for that stripe.
This is current behaviour.  I don't think I can guarantee it will
never changed.

For raid5 it is NOT safe to skip the initial sync.  It is possible for
all updates to be "read-modify-write" updates which assume the parity
is correct.  If it is wrong, it stays wrong.  Then when you lose a
drive, the parity blocks are wrong so the data you recover using them
is wrong.

In summary, it is safe to use --assume-clean on a raid1 or raid1o,
though I would recommend a "repair" before too long.  For other raid
levels it is best avoided.