Re: Why stacking softraid disciplines is not supported?

> On 29 Nov 2018, at 15.24, Joel Sing <joel@sing.id.au> wrote:
>
> 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.

Thanks! This helped a lot. In addition I did read the original paper
about softraid and looked around the code.

> generically, or by implementing specific disciplines that would
> be commonly used (e.g. RAID 1C, RAID 10, RAID 10C, RAID 5C, etc...).

Would adding a new RAID 1 Crypto discipline be as 'simple' as creating a new
softraid_raid1_crypto.c and adding the init function to the sr_discipline_init?

Having each mode as a separate discipline has the advantage that the whole
framework can be pretty simple. At least to my untrained eye softraid seem very
uncomplicated functionality. Having separate disciplines could lead to duplication,
but this can be battled by having common set of functions that can be shared.

It seems that I found a project for the Christmas holidays :)

- Justus