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