Intel Matrix RAID Question

Sovereign

2[H]4U
Joined
Mar 21, 2005
Messages
3,098
If I have Matrix RAID (ICH9R) w/two 750GB drives and a 2TB drive, I can tell the Matrix Storage Manager to create a RAID5 volume using some space on the 2TB drive as well as the 750s. Is it possible to access the "leftover" 1250GB on the 2TB drive?

I don't care if I have to boot into Linux via a LiveCD and muck with things...complicated solutions are fun :D
 
the answer to your question is NO. Once the RAID controller allocates the 750GB off of the 2TB drive, the rest is unavailable to the machine, and to the OS. The RAID controller would have to present the remaining ~1250GB of space, in order for the OS to be able to use it. By definition, the RAID controller will take all disks in the RAID set, and allocate the lowest common denominator (size) of all of the drives in the set * number of drives, and make that the available RAID size (taking any parity into consideration). For example:

1x 500GB
2x 320GB
1x 250GB

Lowest common denominator is 250GB, and there are 4 disks. RAW space available to configure with the RAID controller will be 250GB * 4 = 1TB. If it's a RAID-1, you'll only get 500GB usable, before formatting. If it was a RAID-5, you'd get 750GB usable, before formatting.

This, of course, assumes all drives are the same rotational speed, have the same amount of cache, the same connectivity speed supported (SATA 1.5Gbps, 3gbps, etc), and have identical access times, sustained reads, sustained writes, etc. Usually, it is best to only create raid groups ouf of drives that are identical. Some RAID controllers are smart enough to actually not allow you to use drives with different RPMs, cache sizes, etc. However, I have never seen ANY RAID controller that would limit array creation based solely on model # comparisons.
 
I'm not sure that answer is correct... I recall the Intel ICH9R allows you to use less than the entire drive for an array and make multiple arrays on the same disks. For example, you could take 2 1TB drives, make a 200GB RAID-1 array, a 1600GB RAID-0 array.
 
I'm not sure that answer is correct... I recall the Intel ICH9R allows you to use less than the entire drive for an array and make multiple arrays on the same disks. For example, you could take 2 1TB drives, make a 200GB RAID-1 array, a 1600GB RAID-0 array.

Matrix RAID does allow multiple logical RAID volumes (up to 2) per physical set of array member disks. However, the rules of lowest common denominator still apply. If you take my previous example:

1x 500GB
2x 320GB
1x 250GB

You would be able to create 2 RAID volumes on the set of 4 physical disks. However, because of the lowest common denominator considerations, you would still be limited to a maximum addressable size of 250GB * 4 disks = 1TB RAW, unformatted space. However, you could do something like this:

4 spindles available, 250GB per spindle
4* 160GB = RAID-5 volume = 480GB available, before formatting
4* 90GB (remaining capacity) = RAID-0 = 360GB available, before formatting

RAID was never designed to accommodate drives of different sizes. Most controllers will try to preclude you (real controllers, that is... not host-RAID, ie fake-RAID solutions like Matrix-RAID) from making a RAID set, at all, from disks with different specs, such as:

1.) Rotational speed
2.) Disk size
3.) Cache size
4.) SMART status
5.) Read speed
6.) Write speed
7.) Access times

If any of the above parameters are outside of acceptable tolerances (on most standalone controllers), the creation of a RAID set will not be allowed.

At any rate, to address the response from Stereodude, you cannot get around the limitations of the lowest common denomination disk, even with Matrix RAID.

Additionally, if you did do something as I described above, you would be best off to not address (initialize and format) both volumes by the same OS. Doing so (whether you want to call it initializing, mounting, whatever) will cause any data access across RAID volumes to be slow. Not only will the OS that's using the RAID-5 set have to use the CPU to arbitrate I/O for the physical disks, it now has to figure out which partition of those physical disks it needs to access. Once that's done, the paged I/O request will cause the read heads to seek the tracks on the drive from the second RAID set, causing further disk contention.

Yes, this means that you CAN have a RAID-0 and a RAID-5 on the same set of physical disks (provided that you have enough spindles to support the levels of RAID that you are trying to achieve), however, due to the increase in disk contention, between the logical separations of RAID sets #1 and #2. If you are not doing heavy read/writes, you can use this type of setup to keep your data which needs some level data protection. The problem is that on a host-RAID system (like all of the Intel ICH controllers, Nvidia controllers, etc.... the ones that come on-board) uses the CPU and RAM in the host system to compute the parity and disk configuration, as well as the array read and writes. There's a driver and an OS sitting in between the CPU/RAM in the system, and the data on the disk. There's also the motherboard chipset. If any of those things go, it is VERY unlikely that your array will be readable, or recoverable. In other words, your ICH chipsets RAID function is not only a function of the driver, the OS, your system RAM, and CPU, but it is also limited to those resources. Furthermore, the chances of being able to migrate the array to a new motherboard is not very good. For instance, you may find yourself stuck on ICHxxR chipset controllers because you have no wy to migrate your data... no spare set of disks that can hold all of your data as a temporary solution to facilitate a move, to say... a real RAID controller.

ICH RAID functions are fine if you just want the functionality, but I would emplore you to not use them for RAID-5. I have used RAID-5 in my Sager Laptop. I have used Matrix RAID to have a RAID-5 and a RAID-0, with different OS's on each RAID set, and with both RAID sets accessed by the same OS. The performance was terrible.

If you want my suggestion, just don't ever assume that MatrixRAID has your back, or that your data's safe. If you get a RAM error, the Intel driver that your OS is using can cause data corruption on your drives. I have had a memory error due to overclocking which caused a BSOD cause my Intel RAID driver to become corrupted, and all of the data to be inaccessible, and unaddressable. Not only did I have to reload the OS, but I lost all of the data on the drives. You may think "well, that's what can happen when you overclock." Yes and no. Memory errors happen all the time, but unless you're running ECC, they do no usually manifest in a BSOD. The OS has no way to correct memory errors, that's what ECC, FB-DIMM, and Chipkill are for... the RAM has to do it. Without these, the OS tries to keep chugging along...and will, until it hits a wall. I was merely forcing the issue, by overclocking. However, I have seen the same thing in a non-OC'd identical laptop, also with an ICH Matrix RAID setup, with the same results. The problem was the RAM.

Just don't count on performance, or data integrity, and you'll be fine. I'd say unless you plan to run two separate RAID-0's in MatrixRAID, with two different OS's loaded...don't bother.
 
Matrix RAID does allow multiple logical RAID volumes (up to 2) per physical set of array member disks. However, the rules of lowest common denominator still apply. If you take my previous example:

1x 500GB
2x 320GB
1x 250GB

You would be able to create 2 RAID volumes on the set of 4 physical disks. However, because of the lowest common denominator considerations, you would still be limited to a maximum addressable size of 250GB * 4 disks = 1TB RAW, unformatted space. However, you could do something like this:

4 spindles available, 250GB per spindle
4* 160GB = RAID-5 volume = 480GB available, before formatting
4* 90GB (remaining capacity) = RAID-0 = 360GB available, before formatting

RAID was never designed to accommodate drives of different sizes. Most controllers will try to preclude you (real controllers, that is... not host-RAID, ie fake-RAID solutions like Matrix-RAID) from making a RAID set, at all, from disks with different specs, such as:

1.) Rotational speed
2.) Disk size
3.) Cache size
4.) SMART status
5.) Read speed
6.) Write speed
7.) Access times

If any of the above parameters are outside of acceptable tolerances (on most standalone controllers), the creation of a RAID set will not be allowed.

At any rate, to address the response from Stereodude, you cannot get around the limitations of the lowest common denomination disk, even with Matrix RAID.

Additionally, if you did do something as I described above, you would be best off to not address (initialize and format) both volumes by the same OS. Doing so (whether you want to call it initializing, mounting, whatever) will cause any data access across RAID volumes to be slow. Not only will the OS that's using the RAID-5 set have to use the CPU to arbitrate I/O for the physical disks, it now has to figure out which partition of those physical disks it needs to access. Once that's done, the paged I/O request will cause the read heads to seek the tracks on the drive from the second RAID set, causing further disk contention.

Yes, this means that you CAN have a RAID-0 and a RAID-5 on the same set of physical disks (provided that you have enough spindles to support the levels of RAID that you are trying to achieve), however, due to the increase in disk contention, between the logical separations of RAID sets #1 and #2. If you are not doing heavy read/writes, you can use this type of setup to keep your data which needs some level data protection. The problem is that on a host-RAID system (like all of the Intel ICH controllers, Nvidia controllers, etc.... the ones that come on-board) uses the CPU and RAM in the host system to compute the parity and disk configuration, as well as the array read and writes. There's a driver and an OS sitting in between the CPU/RAM in the system, and the data on the disk. There's also the motherboard chipset. If any of those things go, it is VERY unlikely that your array will be readable, or recoverable. In other words, your ICH chipsets RAID function is not only a function of the driver, the OS, your system RAM, and CPU, but it is also limited to those resources. Furthermore, the chances of being able to migrate the array to a new motherboard is not very good. For instance, you may find yourself stuck on ICHxxR chipset controllers because you have no wy to migrate your data... no spare set of disks that can hold all of your data as a temporary solution to facilitate a move, to say... a real RAID controller.

ICH RAID functions are fine if you just want the functionality, but I would emplore you to not use them for RAID-5. I have used RAID-5 in my Sager Laptop. I have used Matrix RAID to have a RAID-5 and a RAID-0, with different OS's on each RAID set, and with both RAID sets accessed by the same OS. The performance was terrible.

If you want my suggestion, just don't ever assume that MatrixRAID has your back, or that your data's safe. If you get a RAM error, the Intel driver that your OS is using can cause data corruption on your drives. I have had a memory error due to overclocking which caused a BSOD cause my Intel RAID driver to become corrupted, and all of the data to be inaccessible, and unaddressable. Not only did I have to reload the OS, but I lost all of the data on the drives. You may think "well, that's what can happen when you overclock." Yes and no. Memory errors happen all the time, but unless you're running ECC, they do no usually manifest in a BSOD. The OS has no way to correct memory errors, that's what ECC, FB-DIMM, and Chipkill are for... the RAM has to do it. Without these, the OS tries to keep chugging along...and will, until it hits a wall. I was merely forcing the issue, by overclocking. However, I have seen the same thing in a non-OC'd identical laptop, also with an ICH Matrix RAID setup, with the same results. The problem was the RAM.

Just don't count on performance, or data integrity, and you'll be fine. I'd say unless you plan to run two separate RAID-0's in MatrixRAID, with two different OS's loaded...don't bother.

pwned
 
Back
Top