quoted

If this is the only case where it would be useful, wouldn't it be better
to add an option to mdadm --grow specifying a new raid level, if
different? That way you could take your /dev/md9 raid1 and do:

mdadm --add /dev/md9 /dev/sdc1
mdadm --grow -n 3 /dev/md9 --level=5

or

mdadm --add /dev/md9 /dev/sdc1 /dev/sdd1
mdadm --grow -n 4 /dev/md9 --level=6

or convert a raid5 to raid6 in like fashion, for that matter.

That would do 2 things in one, convert the raid level and grow the
stripes.

On the other hand, if 3 disk raid6 where allowed, then this could be
broken down into 2 simple operations for the userspace: 1) change raid
level without restriping, 2) restripe, which we already know how to
do.

To me it just seems easier to teach the kernel to online reload a raid
device with a different raid mode without any changes, covering
conversion of 1<->4, 1<->5 and 1<->6 in both directions, than to
combine the 2 steps.

That would only leave conversion from 4/5 <-> 6 as complicated case.

That's really what I'm getting at. In the 4/5 <-> 6 case the level
conversion would require a reshape and either changing the number of
devices or shrinking the array. This implies the need for the userspace to
convey to the kernel both the level conversion and the new number of
devices at the same time. Once that is possible, why not use it for 1 <->
6 and all the others too?

And hey, maybe I am crazy and do want a 3 disk raid6 next to my 2 disk
raid5, my 1 disk raid10, my 1 disk raid1 and my 1 disk raid0. :)
The limitation in the kernel just seems arbitrary, that is unless one
of the raid algorithms would break down with just 3 disks.

I don't disagree that if a three disk raid6 is possible in theory then it
might as well be supported. I'm merely suggesting that there ought to be a
better way to do level conversion than creating a new array on top of the
old one.