Re: RAID5 losing initial synchronization on restart when one disk is spare

[Hubert Verstraete <hubskml@free.fr>]

Dan Williams wrote:
> On Thu, Jun 12, 2008 at 6:05 AM, Hubert Verstraete <hubskml@free.fr> wrote:
>> Neil Brown wrote:
>>> On Wednesday June 11, hubskml@free.fr wrote:
>>>> By the way and FYI, with my configuration, all disks on the same
>>>> controller, internal bitmap, v1 superblock, ... the initial RAID-5
>>>> synchronization duration is the same whether I'm using the option --force or
>>>> not.
>>> For this to be a valid test, you need to fill one drive up with
>>> garbage to ensure that a resync is no a no-op.
>>>
>>> If you don't use the "--force" option, then the recovery process will
>>> read from N-1 drives and write to 1 drive, all completely sequentially
>>> so it will go at a predictable speed.
>>>
>>> When you use "--force" it will read from N drive and check parity.
>>> When it finds an error it will re-write that parity block.
>>> So if the parity blocks happen to be all correct (as probably was the
>>> case in your experiment), it will run nice and fast.  If the parity
>>> blocks happen to all be wrong (as is likely when first creating an
>>> array on drives that weren't an array before) it will be much slower.
>> I've just filled all the drives with /dev/zero and am currently building a
>> new array. Is this a valid test or should I fill the drives with /dev/random
>> ?
>
> No, /dev/zero will not work for this test since the xor sum of zeroed
> blocks is zero.  The check operation has the following stages: read
> the parity from disk, verify it is correct, and if it is not correct
> calculate / writeback correct parity.  So, you need to ensure that the
> parity check fails.  Using /dev/urandom should be sufficient.  Do not
> use /dev/random as it will exhaust the entropy pool and then block.

Confirmed, I got the same resync time after zeroing the hard drives.

Nevertheless, let's say I build the arrays on brand new disks.
If I can assume these disks are full of zero, I can freely choose my 
initial resync method :)
And it seems my new Seagate disk is made of zero (currently running a 
diff with /dev/zero).

Thanks for explanations.
Hubert