Tuesday 21 January 2014

Re: [RFC/CFT] Trusty work for dmraid

On 20 January 2014 12:03, Stefan Bader <stefan.bader@canonical.com> wrote:
> We had been discussing some changes to dmraid at the last vUDS[1]. One part was
> to move Intel Matrix Storage Manager (IMSM) fakeraid users over to mdraid. The
> other part was to verify whether we can stop using dm-raid45 (which is a special
> module the ubuntu kernel ships but has not been maintained for a while) and make
> dmraid use the dm-raid module instead (this one is included in the upstream kernel).
>
> I have prepared changes for both[2] which did work for IMSM (before I disabled
> support) and a RAID5 I had there. Currently there would only be one drawback
> which is that cases which store meta-data at the beginning of a disk and data
> after that would not work. But I am not sure whether there are cases out there
> that work like this.
>
> The support for RAID4 and RAID5 in dmraid also is rather limited:
> ddf1 : SNIA DDF1 (0,1,4,5,linear)
> nvidia : NVidia RAID (S,0,1,10,5)
> [isw : Intel Software RAID (0,1,5,01)]
>
> So practically the only setups to worry are NVidia controllers supporting RAID5
> and those using DDF1 using RAID4 or 5. Are there people out there which have
> BIOS-/fakeRAID configs enabled for RAID4 or 5 and currently use dmraid to set
> those up under Linux?
> One alternative option would be to check whether mdadm DDF support also includes
> everything that dmraid did. At least a quick test with a ddf1 RAID5 which I did
> set up using mdadm seems to be found by dmraid scanning, too.
> That option would leave us only with NVidia controllers depend on dmraid RAID5.
>
> -Stefan
>
> Btw, to make mdadm automatically add the IMSM RAID I have to add the following
> line to /lib/udev/rules.d/64-md-raid.rules:
>
> # handle potential components of arrays (the ones supported by md)
> ENV{ID_FS_TYPE}=="linux_raid_member", GOTO="md_inc"
> +ENV{ID_FS_TYPE}=="isw_raid_member", GOTO="md_inc"
> GOTO="md_inc_skip"
>

Thanks a lot for this. All of it looks wonderful.

I would not want to disable ISW / IMSM compile-time support in dmraid.
And instead add more trickery in the activation rules.

1) if there is no mdmon binary present (on the system or in the
initramfs) -> dmraid must continue to setup all fakeraid
2) if there is mdmon binary, dmraid should do nothing for ddf/isw
raids as mdadm will activate those
3) mdadm/mdmon should activate all raid devices.
4) .... unless there is a kernel cmdline nomdmonddf / nomdmonisw (or
similar in spirit "revert to dmraid" flags) in which case dmraid will
activate ddf/isw instead of the default mdadm

I want to go this route, as it provides easier upgrade paths:
* since I don't want to force "Package: dmraid \n Depends:mdadm" since
isw support is removed from dmraid.
* people may boot old initramfs / generate initramfs with dmraid but
without mdadm (somehow by accident, or mid-upgrade, etc)

You can see prelimenary support for above initramfs/mount ordering for
dmraid here:
https://launchpadlibrarian.net/158604007/dmraid_1.0.0.rc16-4.2ubuntu1_1.0.0.rc16-4.2ubuntu2~70~ubuntu14.04.1.diff.gz

Similar checks will need to be added to mdadm rules to guard
'ENV{ID_FS_TYPE}=="isw_raid_member", GOTO="md_inc" jump.'

Otherwise your patches look good.

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel