Hello All,

I believe I read all there is on the net about software/firmware RAID, but I could not find a clear relationship between the "volumes" set up by the Intel Matrix Storage Manager Option ROM (v8.0.9 on a Tyan S7025 motherboard) and the devices the mdadm handles.

What I try to achieve is to use the option ROM to configure two SATA devices to act in a part RAID0 part RAID1 setting, keeping all the OS and root FS on the first array, and my user space on the latter array (kernel 2.6.31, mdadm 3.0.3).

After setting the "volumes" up by using the option ROM, my /dev/sda and /dev/sdb disks contain what the next two listings show:


I created a temporary mdadm configuration file as in the following listing (1):

By running

I get

Practically, it creates a container of the two /dev/sd[ab] devices, but none of the two volumes that I am really after. The output of

is

whereas

says

I believe this is what is supposed to happen, but I am not sure. In my understanding, "partitioning" by using the option ROM would allow me to boot very easily from the first raid array, that I could also further partition using Linux tools (fdisk or cfdisk?) As such, I would not need to partition both drives before creating the RAID arrays... Nevertheless, I am puzzled by the "volume" as a device: mdadm mentions only real disk devices and partitions.

Can mdadm work with the Intel matrix volumes, and if it does, is that supposed to offer a better performance than "pure" software RAID set up of individual partitions? How do I assemble such a device? Or do I need to delete the volumes, partition the drives, and build the container and the arrays within in the way documented pretty much everywhere? If so, is the ICH10R controller really helping out in boosting the performance of the arrays?

dmraid -ay does find and initialize the two "volumes", but I would like to use mdadm alone, or am I on the totally wrong track?

Your help is highly appreciated. Thanks ahead,
Tibor

dmraid is the tool to use for firmware raid, by insisting on mdadm, you are on the totally wrong track IMO. Is there something wrong with dmraid?

mdadm v > 3.0.3 does support IMSM directly, and it has a more "direct" connection with the kernel, at least the way I understand it. Furthermore, I keep bumping into statements as mdadm is going to be the "standard" in Linux for RAID device control/handling, so I believe it would be beneficial to go the mdadm way.

I am puzzled by the FW raid in general. If you are willing to help me clarify things on the subject, you could take a look at another, quite old and totally un-answered, post of mine.

Thanks for your interest and help so far.

Sure, where's the old post?

My understanding, for what it's worth, which isn't much, is that once the raid has been established by dmraid, that the device manager in the kernel does all the work (it is software raid after all) so that there is essentially no difference in functionality between mdadm and dmraid - except for maintenance tools I suppose.

I haven't a clue about mdadm's handling of the situation, but the error messages it's throwing are not reassuring. Still, I suppose you could try partitioning/formatting the raid devices it shows, something like

fdisk /dev/md/imsm0 or fdisk /dev/md/Volume1

followed by the formatting of your choice assuming partitioning is successful.

Just click on Openumerix to search for all my posts. It is bears the subject line "mdadm v3.0.3 used as in pure software vs. fake RAID setup"

I believe you have just answered it to some extent.

Regarding the current subject, I do not even obtain a /dev/md/Volume[01] device, as I hope I should, but think I shouldn't . So there is nothing to partition. The only device I obtain is /dev/md127, which seems to be nothing but a container of the two actual disks, that is, /dev/sda and /dev/sdb. The superblocks of these contain the Volume0 and Volume1 "volumes" of RAID 0 and RAID 1 levels, respectively. Nevertheless, they do not get assembled by "mdadm -Asvc ..."

Thanks again.

Found your old post: I remember seeing it; didn't answer it because I don't know of any good actual data/benchmarks to compare speeds. I suppose if you ever get it going without dmraid, then you can redo it with dmraid and run some benchmarks to compare, answering the question for good.

As for the current project, I've reached my maximum state of incompetence on the subject at this point; you might try the developers for mdadm and or dmraid and see if they can shed some light on the subject.

EDIT: actually I found this

http://osdir.com/ml/linux-raid/2009-06/msg00009.html

which seems helpful, looks like you have to use "-e imsm" with mdadm

Yes, -e imsm sets the type of the superblock. That however, is already set by the metadata=imsm parameter that the mdadm -Ebsc returns, and I got captured in the mdconfig.tmp file.
Thanks again for your good will and time to help.

OK, I got it. There is a tiny note in the "ANNONCEMENT 3.0.3" of mdadm, which a first seems to indicate an unacceptably simple and easy way to get to the finish line. As it turns out, it works like a charm. Here's what I did.

1) Created the Intel Matrix volumes using the option ROM (v8.9.0 for ICH10R/DO on a Tyan S7025 motherboard using 2 SATA hard disks).
2) Booted the system - I have my own "distribution" derived from LSF/CLFS on a USB flash memory key (kernel 2.6.31.6)
3) Issued
which assembled the IMSM container of the real /dev/sd[ab] block devices
4) Issued
which built the actual raid devices inside the container. These are the RAID1 and RAID0 Intel Matrix volumes I was so much after (they got created under the name of /dev/md126 and /dev/md127)
5) Partitioned the two raid arrays, /dev/md126 and /dev/md127 using cfdisk.
6) Formatted the partitions.

That was it. What puzzles me is that the superblock type became v 0.90, and not "imsm" while that was there inherently in the superblock of the container. I'm not sure what this means, so I will do it again, using
and
at steps 3) and 4).

My newest problem is that I could not get GRUB 1.97.1 see the bootable partition /dev/md126p1 that I created on /dev/md126. All ideas for making this "fake RAID" setup boot are welcome. Thanks.

Grub 1.97 I know nothing about. Grub 0.97 sees dmraid partitions (can't remember if there was a patch needed or not), so it *should* see anything the bios sees...