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:
  

quoted

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:
  

quoted

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:
  

quoted

[   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