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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dan Williams wrote:
On Tue, Jun 10, 2008 at 4:57 AM, Hubert Verstraete <hubskml@xxxxxxx> wrote:
Hubert Verstraete wrote:
Hello

According to mdadm's man page:
"When creating a RAID5 array, mdadm will automatically create a degraded
array with an extra spare drive. This is because building the spare
into a degraded array is in general faster than resyncing the parity on
a non-degraded, but not clean, array. This feature can be over-ridden
with the --force option."

Unfortunately, I'm seeing a kind of bug when I create a RAID5 array with
an internal bitmap, then stop the array before the initial synchronization
is done and restart the array.

1° When I create the array with an internal bitmap:
mdadm -C /dev/md_d1 -e 1.2 -l 5 -n 4 -b internal -R /dev/sd?
I see the last disk as a spare disk. After the restart of the array, all
disks are seen active and the array is not continuing the aborted
synchronization!
Note that I did not use the --assume-clean option.

2° When I create the array without a bitmap:
mdadm -C /dev/md_d1 -e 1.2 -l 5 -n 4 -R /dev/sd?
I see the last disk as a spare disk. After the restart of the array, the
spare disk is still a spare disk and the array continues the synchronization
where it had stopped.

In the case 1°, is this a bug or did I miss something?
Secondly, what could be the consequences of this non-performed
synchronization ?

Kernel version: 2.6.26-rc4
mdadm version: 2.6.2

Thanks,
Hubert
For the record, the new stable kernel 2.6.25.6 has the same issue.
I thought maybe the patch "md: fix prexor vs sync_request race" could have
fixed this, unfortunately not.


I am able to reproduce this here, and I notice that it does not happen
with v0.90 superblocks.  In the v0.90 case when the array is stopped
the last disk remains marked as spare.  The following hack seems to
achieve the same effect for v1 arrays, but I wonder if it is
correct... Neil?

Thanks Dan.
I quickly tried your patch on 2.6.25.6, unfortunately it did not fix the issue.

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

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux