[RFC/CFT] Trusty work for dmraid

[Stefan Bader]

On 21.01.2014 09:37, Stefan Bader wrote:
> On 20.01.2014 22:33, Phillip Susi wrote:
>> On 1/20/2014 7:03 AM, Stefan Bader wrote:
>>> 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.
>>
>> What do you mean?  isw always stores its meta data at the end of the disk.
> 
> isw might be true. Since we want to move support of isw/imsm (two acronyms for
> the same) to mdadm. This is no issue. More for ddf1 or nvidia. And even for
> those it could depend on config. While looking through HW I have sitting around
> I stumbled over a sil controller that allowed raid5 (before realizing that
> dmraid would not support that). This one had otheros sw which had options to
> convert arrays legacy and some other format. I assume legacy means meta-data at
> the end, then at least the boot sectors might be in the right place. Other type
> of format could mean meta-data and signature at the beginning.

That said, I would read the meta-data code in dmraid as if the data (at least
for ddf1 and nv) is always at offset 0. So its more being overly suspicious that
I might have missed something in there.

> 
>>
>>> 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?
>>
>> DDF1 may be fairly common on servers since this is the usual format
>> used by server class fakeraid cards, and servers are typically set up
>> using raid5.
> 
> Yes, I also thought that ddf1 (apparently Adaptec controllers also tend to use
> this format) would be the more common.
>>
>>> 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.
>>
>> Last I saw on the linux-raid mailing list they were still shaking a
>> few bugs out of the ddf support in mdadm.  nvidia controllers seem to
>> mainly have been used in enthusiast/gamer/workstation desktop boards
>> where raid0 is far more likely than raid5.
> 
> True, probably a lot of cases cannot even try. Like I got one board with nvidia
> fakeraid but that only supports 0 and 1 (maybe jbod, too).
> 
>>
>>> 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"
>>
>> What about making sure that dmraid *isn't* used to activate the array?
> 
> That is done by the modified dmraid source. It has all isw support removed. The
> above is just needed to make the array appear on boot using mdadm. Without it
> you have to manually assemble it.
> 
>>
>>
>>
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20140121/38da7989/attachment.pgp>