Re: Why stacking softraid disciplines is not supported?

On Thursday 29 November 2018 12:05:08 Justus Hämäläinen wrote:
> Hi,
>
> I see that stacking softraid disciplines is not supported, but why I
> wonder? I was thinking about running fulldisk encryption on softraid
> RAID1.
>
> Is it unsupported because it hasn't been tested enough that it doesn't
> explode? (Can do this myself)
> Is it just unimportant enough that nobody has worked on this? (I can at
> least waste my time on this)
>
> Or is it just plain stupid idea? If so why it shouldn't be done?

It works and you can do it, but it is not officially supported - as in if it
breaks you get to either keep both bit... or figure out how to fix it yourself
(I have done it myself in the past, for example).

There is no technical reason for it not to work, however there are several
"gotchas" that you need to be aware of, along with several inefficiencies. The
two main things are that boot and auto-assembly will not work - the boot
loader will assemble the first softraid volume, but it will not find or assemble
the stacked volume. Same goes with auto-assembly by the kernel at boot time
(for a non-boot disk).

The inefficiency comes from the fact that each discipline is attached and
exposed as a separate sd(4) device, which means that reads/writes effectively
get performed on one virtual device, before bouncing around and being
performed on the second virtual device, before bouncing around and being
performed on the actual underlying physical devices. Ideally this would be
handled internally so that you handle the (for example) crypto transformation,
then RAID 1 transformation, then write to the physical devices - this way you
also only expose one sd(4) device for the volume (which also avoids things
messing with the intermediate discipline). There are a few ways that this
could be done - generically, or by implementing specific disciplines that would
be commonly used (e.g. RAID 1C, RAID 10, RAID 10C, RAID 5C, etc...).

Hope this helps.