Initial degraded RAID6 sync doesn't occur? Kernel reports it as RAID5?

Initial degraded RAID6 sync doesn't occur? Kernel reports it as RAID5?

[Bas van Schaik]

Dear all,

A while ago I created a RAID6 array of 5 devices of which one was
'missing'. The last disk just didn't arrive in time, so I decided to
create a degraded RAID6 array, actually being equal to a RAID5 in terms
of risks (correct me if I'm wrong).

When creating the device, md refused to start it. I'm very sorry not to
be able to provide the exact output, because it is already a few weeks
ago and I didn't pay that much attention to it by then. The command I
used to create the array was:
> mdadm --create /dev/md5 --level raid6 --raid-devices 5
> /dev/sd{a,b,c,d}5 missing

After that, I had to force assembly to be able to actually use the array:
> mdadm --assemble --force /dev/md5 /dev/sd{a,b,c,d}5

This did work, but it didn't trigger an initial sync of the RAID6 array.
Correct me if I'm wrong, but that initial sync should be performed for
the single redundancy block, shouldn't it?

We're a few weeks later now, and the missing disk has arrived. When
adding it to the array, the value in /sys/block/md5/md/mismatch_cnt
obviously explodes: the syndromes P and/or Q were never computed and
thus mismatch on a large part of the disk. After performing an repair
(echo repair > sync_action) these syndromes are back in sync and the
problem of mismatching blocks disappears. A e2fsck on the filesystem on
top of the array does not indicate any problems at all.

Summarizing the above: shouldn't mdadm perform an initial sync on a
degraded RAID6 array (missing 1 drive)?

The second observation I have made in this process: the kernel reports
my RAID6 array as being a RAID5 array on some places. For example, a
piece of `dmesg` output after adding the 5th disk and rebooting:
> [   68.526355] raid5: raid level 6 set md5 active with 4 out of 5
> devices, algorithm 2
> [   68.526404] RAID5 conf printout:
> [   68.526405]  --- rd:5 wd:4
> [   68.526406]  disk 0, o:1, dev:sdc5
> [   68.526407]  disk 1, o:1, dev:sdd5
> [   68.526409]  disk 2, o:1, dev:sde5
> [   68.526410]  disk 3, o:1, dev:sdf5
> [   68.526677] RAID5 conf printout:
> [   68.526678]  --- rd:5 wd:4
> [   68.526680]  disk 0, o:1, dev:sdc5
> [   68.526681]  disk 1, o:1, dev:sdd5
> [   68.526682]  disk 2, o:1, dev:sde5
> [   68.526683]  disk 3, o:1, dev:sdf5
> [   68.526684]  disk 4, o:1, dev:sda5

/proc/mdstat does show the correct output. From the output of `ps aux` I
can derive that RAID6 is actually managed by a kernel process named
"md5_raid5". I assume RAID6 is implemented as a special case of RAID5
(or theoretically the other way around, of course), but I think it is a
little bit confusing that md reports the array as being of type RAID5.

Regards,

  Bas

Re: Initial degraded RAID6 sync doesn't occur? Kernel reports it as RAID5?

[Bas van Schaik]

Dear all,

Bas van Schaik wrote:
> Dear all,
>
> A while ago I created a RAID6 array of 5 devices of which one was
> 'missing'. The last disk just didn't arrive in time, so I decided to
> create a degraded RAID6 array, actually being equal to a RAID5 in terms
> of risks (correct me if I'm wrong).
>   
I'm sorry for self-replying this post, but I forgot to mention the
kernel version I'm using. I was somehow convinced of the fact that I was
running a recent kernel, but it turns out to be 2.6.24 (from Ubuntu
Hardy). Unfortunately I cannot upgrade this kernel to the latest version
to check if my questions/observations still hold.

  -- Bas


> When creating the device, md refused to start it. I'm very sorry not to
> be able to provide the exact output, because it is already a few weeks
> ago and I didn't pay that much attention to it by then. The command I
> used to create the array was:
>   
>> mdadm --create /dev/md5 --level raid6 --raid-devices 5
>> /dev/sd{a,b,c,d}5 missing
>>     
>
> After that, I had to force assembly to be able to actually use the array:
>   
>> mdadm --assemble --force /dev/md5 /dev/sd{a,b,c,d}5
>>     
>
> This did work, but it didn't trigger an initial sync of the RAID6 array.
> Correct me if I'm wrong, but that initial sync should be performed for
> the single redundancy block, shouldn't it?
>
> We're a few weeks later now, and the missing disk has arrived. When
> adding it to the array, the value in /sys/block/md5/md/mismatch_cnt
> obviously explodes: the syndromes P and/or Q were never computed and
> thus mismatch on a large part of the disk. After performing an repair
> (echo repair > sync_action) these syndromes are back in sync and the
> problem of mismatching blocks disappears. A e2fsck on the filesystem on
> top of the array does not indicate any problems at all.
>
> Summarizing the above: shouldn't mdadm perform an initial sync on a
> degraded RAID6 array (missing 1 drive)?
>
> The second observation I have made in this process: the kernel reports
> my RAID6 array as being a RAID5 array on some places. For example, a
> piece of `dmesg` output after adding the 5th disk and rebooting:
>   
>> [   68.526355] raid5: raid level 6 set md5 active with 4 out of 5
>> devices, algorithm 2
>> [   68.526404] RAID5 conf printout:
>> [   68.526405]  --- rd:5 wd:4
>> [   68.526406]  disk 0, o:1, dev:sdc5
>> [   68.526407]  disk 1, o:1, dev:sdd5
>> [   68.526409]  disk 2, o:1, dev:sde5
>> [   68.526410]  disk 3, o:1, dev:sdf5
>> [   68.526677] RAID5 conf printout:
>> [   68.526678]  --- rd:5 wd:4
>> [   68.526680]  disk 0, o:1, dev:sdc5
>> [   68.526681]  disk 1, o:1, dev:sdd5
>> [   68.526682]  disk 2, o:1, dev:sde5
>> [   68.526683]  disk 3, o:1, dev:sdf5
>> [   68.526684]  disk 4, o:1, dev:sda5
>>     
>
> /proc/mdstat does show the correct output. From the output of `ps aux` I
> can derive that RAID6 is actually managed by a kernel process named
> "md5_raid5". I assume RAID6 is implemented as a special case of RAID5
> (or theoretically the other way around, of course), but I think it is a
> little bit confusing that md reports the array as being of type RAID5.
>
> Regards,
>
>   Bas
> --
> 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
>