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.
>
>>
>>
>>
>
>
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
