IDE/RAID/AHCI setting in BIOS influcencing mdraid?

IDE/RAID/AHCI setting in BIOS influcencing mdraid?

[Martin MOKREJŠ]

Hi,
  after poking around the internet I cannot answer myself several questions.
Please somebody feel free to update the http://linux-raid.osdl.org/ pages
and the mdadm manpage to explain the differences. ;-)

  1. Does the BIOS values, especially AHCI vs. RAID force for example the
ICH9R chip into different mode seen by linux kernel? Looks like that ...
I have two machines and see there is a difference reported. Could that
cause machine instability if the disks would be configured through mdadm
to be in RAID? Some kind of conflict?

  I see "impl RAID mode" vs. "SATA mode" in dmesg outputs on my machines:
host1: ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl RAID mode
host2: ahci 0000:02:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode


  2. Selecting RAID mode in BIOS writes some Intel Storage Matrix label
somewhere into the disk, right? I think I read in mdadm manpage or similar about
"imsm" superblock format or something like that ... supported by mdraid. I cannot
find it anymore. Does it mean that one could force mdadm to create the superblock
recognized by the ICH9R BIOS and in theory MS Win drivers from Intel?


  3. I have now 0.90 superblocks on two raid1 disc partitions /dev/sd[a-b]1.
What happens if I go to BIOS of ICH9R and "remove the drives from the raid1" array?
Does that clear the "imsm?" superblock? Will that kill the 0.90 mdadm superblock
and destroy my linux mdraid?


  4. There is hardly a documentation available comparing and explaining
the difference between dmraid and mdraid. My understanding is that dmraid
is used in linux/win dual-boot machines and is older implementation. Does
use of the "imsm" superblock format under mdadm give the same possibility?
BTW, arguably the best documentation is in lkml archives around here ...:-)

From: Neil Brown (neilb@cse.unsw.edu.au)
Date: Tue Nov 19 2002 - 23:09:18 EST
Subject: RFC - new raid superblock layout for md driver

The thread is at http://lkml.indiana.edu/hypermail/linux/kernel/0211.2/1108.html


   5. There is --zero-superblock option to mdadm(1) but the manpage does not bother
to state how can one create one. Googling around I found that actually --create
does not kill the current data if one supplies mdadm with the list of devices.
I would have to Google again to give you the link, sorry. ;-) This one is at least
somehow similar, probably the first where I saw a trick with the devicename "missing".
Something new to me. ;-)
http://ubuntu-ky.ubuntuforums.org/showthread.php?p=8286434


   6. mdadm -D /dev/mdX shows:   "Persistence : Superblock is persistent".
  What I did not create the array with persistent block? How to create one
additionally? I think the answer is in the previous point nr. 5. ;-)
Yes, would be nice if somebody placed into the manpage (your Wiki) a kernel
command-line (for those who screwed their superblocks or want to stay on a safe side
if they manage so ...) example like this one from http://en.gentoo-wiki.com/wiki/Software_RAID_Install:

Title gentoo-2.6.24-r3
root (hd0,0)
kernel /gentoo.2624r3 root=/dev/md5 md=5,/dev/sda5,/dev/sdb5


Thank you for any clarifications.
Martin

Re: IDE/RAID/AHCI setting in BIOS influcencing mdraid?

[Majed B.]

Hello,

I won't be able to answer all your questions, but I can help with some:

1) Each mode in the BIOS makes the devices behave differently. AHCI
always improves performance for disks. My laptop was on IDE and its
max throughput was 11 MB/s. When enabling AHCI, I got 30-35 MB/s out
of the poor disk (5400 rpm).

1 & 2) Intel storage matrix is fake RAID and its driver is horrible &
slow. Avoid it like the plague!
You'd be better off with software RAID or a hardware controller.

3) As far as I know, whenevr you create an array (in any way --
software or hardware), array information is written to the disks, so
when you switch from software RAID to hardware RAID, you may lose your
array information, depending on where the information is written
(beginning of the disk or at the end of it) -- if you have a
filesystem already in place, that may be lost too.
The above is also correct if you tried to create a new software RAID
array but with a different superblock version (0.9 vs 1.x), since
array information is written differently.

A quote from the mdadm manual:
"1, 1.0, 1.1, 1.2: Use the new version-1 format superblock.  This has
few restrictions.  The different sub-versions store the superblock at
different locations on the device, either at the end (for 1.0), at the
start (for 1.1) or 4K from the start (for 1.2)."

On Wed, Nov 11, 2009 at 2:15 AM, Martin MOKREJŠ
<mmokrejs@ribosome.natur.cuni.cz> wrote:
> Hi,
>  after poking around the internet I cannot answer myself several questions.
> Please somebody feel free to update the http://linux-raid.osdl.org/ pages
> and the mdadm manpage to explain the differences. ;-)
>
>  1. Does the BIOS values, especially AHCI vs. RAID force for example the
> ICH9R chip into different mode seen by linux kernel? Looks like that ...
> I have two machines and see there is a difference reported. Could that
> cause machine instability if the disks would be configured through mdadm
> to be in RAID? Some kind of conflict?
>
>  I see "impl RAID mode" vs. "SATA mode" in dmesg outputs on my machines:
> host1: ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl RAID mode
> host2: ahci 0000:02:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
>
>
>  2. Selecting RAID mode in BIOS writes some Intel Storage Matrix label
> somewhere into the disk, right? I think I read in mdadm manpage or similar about
> "imsm" superblock format or something like that ... supported by mdraid. I cannot
> find it anymore. Does it mean that one could force mdadm to create the superblock
> recognized by the ICH9R BIOS and in theory MS Win drivers from Intel?
>
>
>  3. I have now 0.90 superblocks on two raid1 disc partitions /dev/sd[a-b]1.
> What happens if I go to BIOS of ICH9R and "remove the drives from the raid1" array?
> Does that clear the "imsm?" superblock? Will that kill the 0.90 mdadm superblock
> and destroy my linux mdraid?
>
>
>  4. There is hardly a documentation available comparing and explaining
> the difference between dmraid and mdraid. My understanding is that dmraid
> is used in linux/win dual-boot machines and is older implementation. Does
> use of the "imsm" superblock format under mdadm give the same possibility?
> BTW, arguably the best documentation is in lkml archives around here ...:-)
>
> From: Neil Brown (neilb@cse.unsw.edu.au)
> Date: Tue Nov 19 2002 - 23:09:18 EST
> Subject: RFC - new raid superblock layout for md driver
>
> The thread is at http://lkml.indiana.edu/hypermail/linux/kernel/0211.2/1108.html
>
>
>   5. There is --zero-superblock option to mdadm(1) but the manpage does not bother
> to state how can one create one. Googling around I found that actually --create
> does not kill the current data if one supplies mdadm with the list of devices.
> I would have to Google again to give you the link, sorry. ;-) This one is at least
> somehow similar, probably the first where I saw a trick with the devicename "missing".
> Something new to me. ;-)
> http://ubuntu-ky.ubuntuforums.org/showthread.php?p=8286434
>
>
>   6. mdadm -D /dev/mdX shows:   "Persistence : Superblock is persistent".
>  What I did not create the array with persistent block? How to create one
> additionally? I think the answer is in the previous point nr. 5. ;-)
> Yes, would be nice if somebody placed into the manpage (your Wiki) a kernel
> command-line (for those who screwed their superblocks or want to stay on a safe side
> if they manage so ...) example like this one from http://en.gentoo-wiki.com/wiki/Software_RAID_Install:
>
> Title gentoo-2.6.24-r3
> root (hd0,0)
> kernel /gentoo.2624r3 root=/dev/md5 md=5,/dev/sda5,/dev/sdb5
>
>
> Thank you for any clarifications.
> Martin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
       Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IDE/RAID/AHCI setting in BIOS influcencing mdraid?

[Luca Berra]

On Wed, Nov 11, 2009 at 12:15:33AM +0100, Martin MOKREJŠ wrote:
>Hi,
>  after poking around the internet I cannot answer myself several questions.
>Please somebody feel free to update the http://linux-raid.osdl.org/ pages
>and the mdadm manpage to explain the differences. ;-)
i don't believe information about bios settings of a particular
controller belongs in mdadm man page

>  1. Does the BIOS values, especially AHCI vs. RAID force for example the
>ICH9R chip into different mode seen by linux kernel? Looks like that ...
iirc changing the settings from SATA to AHCI or RAID changes the pci id
for the controler, and the kernel driver is different.
I am not sure if changing between AHCI and RAID really matters to the
linux kernel.
>I have two machines and see there is a difference reported. Could that
>cause machine instability if the disks would be configured through mdadm
>to be in RAID? Some kind of conflict?
no, not the bios (AHCI vs RAID) settings, it would if you configured an
array from the controller bios, then used mdadm with a normal metadata
format
>
>  2. Selecting RAID mode in BIOS writes some Intel Storage Matrix label
>somewhere into the disk, right? I think I read in mdadm manpage or similar about
no, that something is written only if you configure an array.

>"imsm" superblock format or something like that ... supported by mdraid. I cannot
>find it anymore. Does it mean that one could force mdadm to create the superblock
>recognized by the ICH9R BIOS and in theory MS Win drivers from Intel?
badly expressed but in short yes,
please read
http://neil.brown.name/git?p=mdadm;a=blob_plain;f=ANNOUNCE-3.0

>  3. I have now 0.90 superblocks on two raid1 disc partitions /dev/sd[a-b]1.
>What happens if I go to BIOS of ICH9R and "remove the drives from the raid1" array?
So you _did_ create an array in the controller bios, and at point 1 and 2
you were giving misleading information?

>Does that clear the "imsm?" superblock? Will that kill the 0.90 mdadm superblock
>and destroy my linux mdraid?
it should clear the imsm metadata from the disk
it should not touch the md metadata
BUT, since the imsm metadata lies somewhere on your disk and you never
told linux about it there is the possibility that some data was
allocated in the same place, sorry.

>  4. There is hardly a documentation available comparing and explaining
>the difference between dmraid and mdraid. My understanding is that dmraid
this is a common problem nowadays, there is a lot of documentation about
many topics, but you never find which documentation is relevant to you
:(

>is used in linux/win dual-boot machines and is older implementation. Does
>use of the "imsm" superblock format under mdadm give the same possibility?
not exactly
as there are many other examples in the open source world you find more
than one software for a similar purpose, neither obsoletes the other.

md was invented to provide software raid to linux well before fakeraids
(and device-mapper) where invented. It used its own metadata format.
It also implement its own kernel code for doing raid stuff.
Recently Neil and others added support for managing metadata in DDF
(and IMSM) format.

When fakeraids first appeared some (few) vendors used to provide a
closed-source binary only linux module to support their raid format.
These mostly sucked. other vendors just did not care about lee-nuks.
with the advent of the 2.6 kernel and adoption of device-mapper in
mainline Heinz created dmraid
dmraid is able to read the metadata format of many fakeraid cards, not
just intel's, and will use device-mapper modules to do raid stuff.
device-mapper already add support for linear, striping and mirror, later
heinz added raid5.
It surely was most useful for dual boot, since it never supported
diagnostics or rebuild features you expect from a raid software, but in
some case the benefit of being able to boot when the first drive failed
outweighted that.
Recently dmraid also supports rebuild and management features, at least
with intel controlers.

so we have two implementations, they both are functioning and
maintained, and they both work in your case.
which one to use is a matter of personal preference.

btw, from time to time there is talk of merging portion of the md raid
code with the device-mapper raid code. It has not happened yet.


L.



-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IDE/RAID/AHCI setting in BIOS influcencing mdraid?

[Martin MOKREJŠ]

Hi everybody,

Luca Berra wrote:
> On Wed, Nov 11, 2009 at 12:15:33AM +0100, Martin MOKREJŠ wrote:
>> Hi,
>>  after poking around the internet I cannot answer myself several
>> questions.
>> Please somebody feel free to update the http://linux-raid.osdl.org/ pages
>> and the mdadm manpage to explain the differences. ;-)
>
> i don't believe information about bios settings of a particular
> controller belongs in mdadm man page

I agree but some clarification what is relation to these fakeraids,
changes in behavior would be helpful. If do not have  a problem if the
information appears on the website (probably related tot this email list?).

> 
>>  1. Does the BIOS values, especially AHCI vs. RAID force for example the
>> ICH9R chip into different mode seen by linux kernel? Looks like that ...
>
> iirc changing the settings from SATA to AHCI or RAID changes the pci id
> for the controler, and the kernel driver is different.
> I am not sure if changing between AHCI and RAID really matters to the
> linux kernel.

There are IDE/AHCI/RAID values.

>> I have two machines and see there is a difference reported. Could that
>> cause machine instability if the disks would be configured through mdadm
>> to be in RAID? Some kind of conflict?
>
> no, not the bios (AHCI vs RAID) settings, it would if you configured an
> array from the controller bios, then used mdadm with a normal metadata
> format

That is what happened to me. Two disks are not in an ICH9R array but are
in raid0 under mdadm. Four disk are under raid10 under ICH9R while also
under raid10 under mdadm.

I observe random lockup for a year or so, either "Aiee, killing interrupt handler",
or black screen on console and flashing LED diodes on the keyboard. However,
the issues are more common since I upgraded to glibc-10. I tried various
kernels, from 2.6.27.38 to 2.6.30.9. Basically I suspect misconfiguration
issue rather then a real hardware issue. I think it is related to heavy IO
and indeed last week I crashed the machine few times after upgrading some
packages which caues lots of reads in $raid10fs/usr/portage tree (Gentoo Linux).

>>
>>  2. Selecting RAID mode in BIOS writes some Intel Storage Matrix label
>> somewhere into the disk, right? I think I read in mdadm manpage or
>> similar about
> no, that something is written only if you configure an array.

That I mistakenly left in some years ago.

> 
>> "imsm" superblock format or something like that ... supported by
>> mdraid. I cannot
>> find it anymore. Does it mean that one could force mdadm to create the
>> superblock
>> recognized by the ICH9R BIOS and in theory MS Win drivers from Intel?
> badly expressed but in short yes,
> please read
> http://neil.brown.name/git?p=mdadm;a=blob_plain;f=ANNOUNCE-3.0

Ah, thanks for the pointer. I have the impression that the new containers do
not replace superblocks. I will try tro re-phrase it: one will not have "imsm"
superblock but drives with 0.9, 1.0, 1.2 can be parts of an "imsm" container,
written somewhere around. I wonder whether such setup would be a safe approach
for me so in a way that I would not have to bother whether I have left in BIOS
settings not only RAID or AHCI value but even a configured array. My understanding
is these "fake-raids" just define what the array is and linux/win drivers have
to do the job, so the BIOS stuff only means that one can define what needs to be
done.

What is still of interest to me whether the RAID or AHCI mode is preferred for
mdraid user although one should avoid defining the array through the "fake-raid"
chip. The previous answer from Majed B. unfortunately only points that AHCI mode
is faster than IDE mode.


> 
>>  3. I have now 0.90 superblocks on two raid1 disc partitions
>> /dev/sd[a-b]1.
>> What happens if I go to BIOS of ICH9R and "remove the drives from the
>> raid1" array?
>
> So you _did_ create an array in the controller bios, and at point 1 and 2
> you were giving misleading information?

Yes, see above.

> 
>> Does that clear the "imsm?" superblock? Will that kill the 0.90 mdadm
>> superblock and destroy my linux mdraid?
> it should clear the imsm metadata from the disk
>
> it should not touch the md metadata
> BUT, since the imsm metadata lies somewhere on your disk and you never
> told linux about it there is the possibility that some data was
> allocated in the same place, sorry.

So best way out is to set ICH9R to AHCI, migrate the data, switch ICH9R tp RAID,
delete the RAID10 array, switch ICH9R to AHCI, create new array under mdadm?

> 
>>  4. There is hardly a documentation available comparing and explaining
>> the difference between dmraid and mdraid. My understanding is that dmraid
>
> this is a common problem nowadays, there is a lot of documentation about
> many topics, but you never find which documentation is relevant to you
> :(
> 
>> is used in linux/win dual-boot machines and is older implementation. Does
>> use of the "imsm" superblock format under mdadm give the same
>> possibility?
>
> not exactly
> as there are many other examples in the open source world you find more
> than one software for a similar purpose, neither obsoletes the other.
> 
> md was invented to provide software raid to linux well before fakeraids
> (and device-mapper) where invented. It used its own metadata format.
> It also implement its own kernel code for doing raid stuff.
> Recently Neil and others added support for managing metadata in DDF
> (and IMSM) format.
> 
> When fakeraids first appeared some (few) vendors used to provide a
> closed-source binary only linux module to support their raid format.
> These mostly sucked. other vendors just did not care about lee-nuks.
> with the advent of the 2.6 kernel and adoption of device-mapper in
> mainline Heinz created dmraid
> dmraid is able to read the metadata format of many fakeraid cards, not
> just intel's, and will use device-mapper modules to do raid stuff.
> device-mapper already add support for linear, striping and mirror, later
> heinz added raid5.
> It surely was most useful for dual boot, since it never supported
> diagnostics or rebuild features you expect from a raid software, but in
> some case the benefit of being able to boot when the first drive failed
> outweighted that.
> Recently dmraid also supports rebuild and management features, at least
> with intel controlers.
> 
> so we have two implementations, they both are functioning and
> maintained, and they both work in your case.
> which one to use is a matter of personal preference.

Or the Install guide one finds first. ;-)

> 
> btw, from time to time there is talk of merging portion of the md raid
> code with the device-mapper raid code. It has not happened yet.

Yeah, that I found by Google.

Thank you,
M.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IDE/RAID/AHCI setting in BIOS influcencing mdraid?

[Dan Williams]

On Thu, Nov 12, 2009 at 9:06 AM, Martin MOKREJŠ
<mmokrejs@ribosome.natur.cuni.cz> wrote:
> Hi everybody,
>
> Luca Berra wrote:
>> On Wed, Nov 11, 2009 at 12:15:33AM +0100, Martin MOKREJŠ wrote:
>>> Hi,
>>>  after poking around the internet I cannot answer myself several
>>> questions.
>>> Please somebody feel free to update the http://linux-raid.osdl.org/ pages
>>> and the mdadm manpage to explain the differences. ;-)
>>
>> i don't believe information about bios settings of a particular
>> controller belongs in mdadm man page
>
> I agree but some clarification what is relation to these fakeraids,
> changes in behavior would be helpful. If do not have  a problem if the
> information appears on the website (probably related tot this email list?).

To Linux:

IDE == ata_piix
AHCI = ahci
RAID == ahci

>
>>
>>>  1. Does the BIOS values, especially AHCI vs. RAID force for example the
>>> ICH9R chip into different mode seen by linux kernel? Looks like that ...
>>
>> iirc changing the settings from SATA to AHCI or RAID changes the pci id
>> for the controler, and the kernel driver is different.
>> I am not sure if changing between AHCI and RAID really matters to the
>> linux kernel.
>
> There are IDE/AHCI/RAID values.

It changes the pci-id, but protocol-wise it is still AHCI.

>
>>> I have two machines and see there is a difference reported. Could that
>>> cause machine instability if the disks would be configured through mdadm
>>> to be in RAID? Some kind of conflict?
>>
>> no, not the bios (AHCI vs RAID) settings, it would if you configured an
>> array from the controller bios, then used mdadm with a normal metadata
>> format
>
> That is what happened to me. Two disks are not in an ICH9R array but are
> in raid0 under mdadm. Four disk are under raid10 under ICH9R while also
> under raid10 under mdadm.

You can use mdadm-3.x to remove whatever superblock you don't need i.e:

mdadm --zero-superblock -e imsm /dev/sdX
-or-
mdadm --zero-superblock -e 0.90 /dev/sdX
etc...

>
> I observe random lockup for a year or so, either "Aiee, killing interrupt handler",
> or black screen on console and flashing LED diodes on the keyboard. However,
> the issues are more common since I upgraded to glibc-10. I tried various
> kernels, from 2.6.27.38 to 2.6.30.9. Basically I suspect misconfiguration
> issue rather then a real hardware issue. I think it is related to heavy IO
> and indeed last week I crashed the machine few times after upgrading some
> packages which caues lots of reads in $raid10fs/usr/portage tree (Gentoo Linux).
>

At first glance this does not sound like a RAID problem, but would
need more information about what is going on around the lockup,
certainly not caused by switching between RAID mode and AHCI mode.

>>>  2. Selecting RAID mode in BIOS writes some Intel Storage Matrix label
>>> somewhere into the disk, right? I think I read in mdadm manpage or
>>> similar about
>> no, that something is written only if you configure an array.

Correct, nothing is written to the disks until you create an array.

>
> That I mistakenly left in some years ago.
>
>>
>>> "imsm" superblock format or something like that ... supported by
>>> mdraid. I cannot
>>> find it anymore. Does it mean that one could force mdadm to create the
>>> superblock
>>> recognized by the ICH9R BIOS and in theory MS Win drivers from Intel?
>> badly expressed but in short yes,
>> please read
>> http://neil.brown.name/git?p=mdadm;a=blob_plain;f=ANNOUNCE-3.0
>
> Ah, thanks for the pointer. I have the impression that the new containers do
> not replace superblocks. I will try tro re-phrase it: one will not have "imsm"
> superblock but drives with 0.9, 1.0, 1.2 can be parts of an "imsm" container,

No.  The metadata is completely separate.  Have a look at the man page
for mdmon in a 3.x mdadm release for a better explanation of
containers.  And please send any detailed questions you have about
that documentation so that we can make it better.

> written somewhere around. I wonder whether such setup would be a safe approach
> for me so in a way that I would not have to bother whether I have left in BIOS
> settings not only RAID or AHCI value but even a configured array. My understanding
> is these "fake-raids" just define what the array is and linux/win drivers have
> to do the job, so the BIOS stuff only means that one can define what needs to be
> done.

It is more than that.  The benefit of RAID mode is that it enables the
platform's option-ROM to allow booting from any supported raid level,
and configuring RAID volumes pre-OS.

> What is still of interest to me whether the RAID or AHCI mode is preferred for
> mdraid user although one should avoid defining the array through the "fake-raid"
> chip. The previous answer from Majed B. unfortunately only points that AHCI mode
> is faster than IDE mode.

You pretty much always want AHCI mode as it has features like hotplug
and better performance.  RAID mode is useful if you want to the use
the option-ROM for booting and RAID configuration.

>>
>>>  3. I have now 0.90 superblocks on two raid1 disc partitions
>>> /dev/sd[a-b]1.
>>> What happens if I go to BIOS of ICH9R and "remove the drives from the
>>> raid1" array?
>>
>> So you _did_ create an array in the controller bios, and at point 1 and 2
>> you were giving misleading information?
>
> Yes, see above

This will delete the Intel metadata which is located at the end of the disk.

>>> Does that clear the "imsm?" superblock? Will that kill the 0.90 mdadm
>>> superblock and destroy my linux mdraid?
>> it should clear the imsm metadata from the disk
>>
>> it should not touch the md metadata
>> BUT, since the imsm metadata lies somewhere on your disk and you never
>> told linux about it there is the possibility that some data was
>> allocated in the same place, sorry.
>
> So best way out is to set ICH9R to AHCI, migrate the data, switch ICH9R tp RAID,
> delete the RAID10 array, switch ICH9R to AHCI, create new array under mdadm?

The Intel metadata is at the end of drive and technically overlaps the
space for the 0.90 format.  The good news is that 0.90 starts at a 4K
offset from the end and grows down while the Intel format starts at
the second to last sector and grows up, so if any collision were to
occur it would have already happened.  To be safe I would backup the
data on the 0.90 array delete both superblocks and restore (the BIOS
setting is a don't care for this procedure).  When you restore choose
between native md metadata or 'imsm', not both :-).  If you choose
'imsm' and want to use the option-ROM's boot-from-raid functionality
select RAID mode otherwise AHCI is sufficient.

>>>  4. There is hardly a documentation available comparing and explaining
>>> the difference between dmraid and mdraid.

Maturity, metadata management, raid4/5/6, raid level migrations, and
capacity expansion.

http://thread.gmane.org/gmane.linux.raid/23034

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IDE/RAID/AHCI setting in BIOS influcencing mdraid?

[Bill Davidsen]

Martin MOKREJŠ wrote:
> Hi everybody,
>
> That is what happened to me. Two disks are not in an ICH9R array but are
> in raid0 under mdadm. Four disk are under raid10 under ICH9R while also
> under raid10 under mdadm.
>   

Could you clarify that last sentence? It sounds as if you have two 
independent arrays, using a controller for one and mdraid for the other, 
and they both use the same drives. Please tell me I'm misreading this...

-- 
Bill Davidsen <davidsen@tmr.com>
  "We can't solve today's problems by using the same thinking we
   used in creating them." - Einstein


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IDE/RAID/AHCI setting in BIOS influcencing mdraid?

[Martin MOKREJŠ]

Hi Bill,

Bill Davidsen wrote:
> Martin MOKREJŠ wrote:
>> Hi everybody,
>>
>> That is what happened to me. Two disks are not in an ICH9R array but are
>> in raid0 under mdadm. Four disk are under raid10 under ICH9R while also
>> under raid10 under mdadm.
>>   
> 
> Could you clarify that last sentence? It sounds as if you have two
> independent arrays, using a controller for one and mdraid for the other,
> and they both use the same drives. Please tell me I'm misreading this...

No, you read it correctly. ICH9R controller has 6 disks connected. First two
do not have configured array "in BIOS" while latter 4 do have (RAID10). That
was my surprise as the machine uses md-array (the first two disks /dev/sd[a-b]1
in raid1, 0.9 superblock) while the latter four /dev/sd[c-f]1 as raid10 (0.9
superblock as well). In other words, the four disks in raid10 are assigned twice,
onder to ICH9R while also to md-raid10.

I think that once I configured the BIOS stuff but used subsequently mdadm to
create the array under linux. Thus I believe I overwrote the "imsm" superblock
without even knowing (but then ICH9R BIOS would not report the RAID10 spanning
the four disks nowadays, right?).

Thanks,
Martin

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html