Tuesday, 21 January 2014

Re: [RFC/CFT] Trusty work for dmraid

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

On 21.01.2014 16:27, Dimitri John Ledkov wrote:
> 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

I see and yeah, that is not as complicated as I thought. Somehow I did not think
about changing the activate script but got stuck wondering about the rule but
that would not allow to handle all the checks that simply.

So mostly I tried to keep the steps separate in my diff which should make it
simple to pick only the parts needed to stop using dm-raid45.
Not sure whether that hack to make configure scripts executable is right either.
But for some reasons some of my builds would have them not and then fail...

> 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.