-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJS3jHbAAoJEOhnXe7L7s6jlDgQAM4no0Ol5IWIbTGv9LRaLn9G
p9k8E0kBi1WFdYYPR54SEz/wgfu8i/A0C290rR+qyVEK9rRypM133aLy+YeoL3fI
0UEVnx4kTqeYMemwuT80/DVs3KDwZIeCvyG4H/CWxVJv5A/0G+CNeCLrlY4g2Z96
sO1oDTRBdEwR05lBJ3x/QTcXayIHLPfND9WmWv0YJQXizh0CgY3FuJ19EE8+tb2z
g17/WnpuAHFztPhTseiIvPX/0StDOo2njYuxXaGpGqCeOTH+7vL00IV1TBXDENb7
4LNwNQu6R8+ryxNMEzF4UU5zlubpvlfAQseijtOYPtw8e/3pgI1nJ2a1Gazw9aEE
dwgCD8bn66l62kigfaqnpSyMO9vTxn5lluSiN5vmb/Ijd+zfY5Sv9adsUAX0SLdL
rIneIOvXgL+5k7Rdu2ve4CPi3cE3qgeKLrVc9SvwMO7SsvodttXKQSszwS4WW1kP
/ob0RV8IDuxienATGg0gfZ59JjBmwykwUqCo5matp8OI8RRp9NQeoS0/2uQd1TiC
MLqBsjvjQGXBr3ArGt+o3djsEaHsx9ToZP+lwX6oD+urLGNkHjZFVARwHDAEIP/I
UXY8tbhCVY/mBbb0ilJ9rU2v0LO2GuEuKobcBaoGifxpyxWvtyCY2OPGTMkWJj/Z
gdIeQC783ddR0nuVsEn+
=80yp
-----END PGP SIGNATURE-----
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.
>
>> 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.
>
>
>
