-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJS3jNSAAoJEOhnXe7L7s6jAdMP/1Mwe+jp2kmvn3MQcKBCKq3u
tgF20ib5x1M3uiqXEL+jf4K7lP5mXu9+tc2m34frwQqcDJNcLE5uWD0rb9KGcmxe
c+vYUj+qKN0oxQi6yiJdwhzvmPjCR0BWvpEpxt+7NPb9Jn83Ayk9n8W1fyerUNF5
X1E06IWJ6542wIwrWH+inxeBTsfrA5StqNl2CCVpTgwaKzapA4Phe9uQ5B6VS1vN
Iukbue+2jWXtxvDPb0W1PYnyvigtfr8oEExrOhYDHsNFQj99WoA5hUPVFsGYuaBb
+OQ4ib7teAHEDaJM8EIiiNEUL5IO83fjDovrz2aKvI7FZBY+xwX6FMsfLmHkIAXK
ykCmYZlDLwJ3pzAvw6aA4szTmFnO8MMF8lRTMt1PcZa6qdSLIWOfuyMZ/fv/Syc8
dZsSBbX0yNqIwvtNmENIEw1Mpum3K01ryRue65l2CeZiGMhavRQzsKFVNV37mU6d
FeD4oINtkfXR8y8B6tY5cDmhDPFfrB7Jj+MPfwLTa3r0m+kAR0bAxqp1MhRpn1bK
fYCChNpxH9VBwgoSCWaFJNzJhFomOy/AGy0SEYiBeOrRIXVTFb8eko5UU2SzIJs8
TXCLetP72aBOOfKkzgcZmxWTIh1R8+SPUggvKAS1EaTVoybFwVy+yLq/ibmmds3M
cJspXEfx89lpq99mxnGh
=oXHP
-----END PGP SIGNATURE-----
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.
>
>>
>>
>>
>
>
