IDE RAID Technical Details

[pm]

I only use SCSI RAID (not IDE), so I'm not sure how IDE RAID works. I've been having a problem finding information on the technical details of exactly what roles the BIOS, the RAID controller and the OS play in IDE RAID. Performing a search for whitepapers only resulted in finding a lot of marketing documentation about how much cheaper IDE RAID is than SCSI RAID.

I was reading this thread here and I was wondering whether IDE RAID0 typically uses persistent superblocks to hold the OS. My Mylex SCSI RAID card has a 2-8GB persistent superblock for booting OS's. A persistent-superblock allows a special type of block to be written in the beginning of all disks participating in the array. This allows the OS kernel to read the configuration of RAID devices directly from the disks involved.

This is mostly a curiousity question. I am curious whether IDE RAID0 behaves like SCSI RAID0, and how does software RAID operate in the absence of an OS. It will also answer the question above, if IDE RAID does use persistent superblocks then it would explain how someone could disconnect a RAID0 device from the array and still boot to Windows.

 

[CTho9305]

according to THG you can't boot from software raid drives - so no persistent blocks (if htere were, they could drop the kernel / raid drivers there)

 

[pm]

That article is about software RAID using the dynamic drive software inside of Win2k. I don't think this is the same thing as the hardware/software implementation of IDE RAID. I see plenty of people booting IDE RAID0 arrays into Windows 2000 in GH, so I don't think that whatever stops you from doing this in Win2k applies to the way IDE RAID works.

 

[CTho9305]

in that case, I guess I don't undrestand the question. hardware RAID is hardware RAID from the OS perspective. one thing im not sure of is whether IDE hardware raid is treated like a SCSI drive or an IDE drive.

 

[Nothinman]

I don't know the specifics but most IDE RAID controllers (the ones from Promise, HighPoint, etc) are just regular ATA/100 controllers with a little firmware magic for booting. The real RAID is done in the driver so by the time the OS loads it looks like hardware RAID and appears as a SCSI drive.

If you use a regular IDE driver you'll see all the drives seperate, a problem many have reported while trying to install Linux on those "arrays" since Linux didn't support the RAID functionality until recently.

 

[pm]

<< in that case, I guess I don't undrestand the question. hardware RAID is hardware RAID from the OS perspective. >>

IDE RAID is like a mix of the two as Nothinman mentioned. It's both hardware and software RAID (but more software than hardware). The question is: if IDE RAID relies heavily on an OS driver to get it working then how can you boot an OS without already having the driver installed (which came first, the chicken or the egg?)? And I think the answer is that a portion of one or all of the IDE RAID drives is set aside to hold the OS in non-striped/mirrored format. But this is just a guess and I can't find any confirmation that this is really what's going on. So I'm curious if anyone can explain exactly how it works.

 

[SilverTorch]

Im not the outmost expert on RAID systems but from what i have read and done RAID is mostly hardware.

the highpoint or the promise chipset does more than provide fancy BIOS options, its a separate IDE controller, that acts differently to data depending on what configuration its using (0, 1, 0+1). RAID 0 is stripping, just "spread" out the data among the drives. RAID 1 just mirrors the drives. Even RAID 0+1 is simple enough stripping and mirroring (4 drives). software does little of this, in fact it does none of it. the fact that built in IDE-RAID solutions that come with ABITs board are so small is that that chip can do only RAID 0, RAID1, and RAID 0+1. The real RAID cards can achieve RAID 5, where a parity bit is calculated, this is where software might come into play or a more powerful chipset perhaps.

thats what i think.
hope this helps, i maybe wrong about some of this too, correct me if you can

 

[Peter]

Same as for booting from any other kind of mass storage controller, RAID or not.

You need the controller's BIOS to support accessing the media through the Int 13h mass storage BIOS
API. This must be supplied - for standard IDE the system BIOS does that, while SCSI and all other
kinds of add-on mass storage controllers bring their own BIOS.

The BIOS and OS boot sequence loads the OS kernel (including the OS's own mass storage drivers)
from the media by calling that Int 13h handler. Then the kernel is started, fires up its own mass
storage drivers, and from that point on accesses the media using those.

What's below a certain controller's Int 13h interface doesn't matter - whether that interface talks to a
hardware RAID engine that has its own brain, or to one or more single drives using its own main
CPU based access methods, doesn't matter. The only thing that does matter is that a given
mass storage controller's Int13h BIOS and its operating system drivers do the same thing.
regards, Peter