Chris Mauritz wrote:

Mark Belanger wrote:

...

I have a dell precision 380: http://catalog.us.dell.com/CS1/CS1Page2.aspx?br=6&c=us&cs=555&fm...

Is CentOS 4.1 an option? I'm not sure if the ICH7R is supported in the newer 2.6 kernels either, but that might be an option for you if you can't make CentOS 3.X work.

The controller will work in RH/Centos 4. At this time I am bound to RH/Centos 3.

-Mark

Craig White craigwhite@azapple.com wrote: http://lists.centos.org/pipermail/centos/2005-August/010021.html

provides the longer view with a link to the original concept but mind you, these are for CentOS 4

The MegaRAID is an i960 solution. The ICH7R is a FRAID solution.

MegaRAID has intelligence and a SCSI driver. The ICH7R _may_ eventually have an ATA "hack," but I seriously doubt it will work well.

In other words, don't bother with it.

Craig White craigwhite@azapple.com wrote:

he asked how to make it work, I gave him a suggestion on that and didn't offer any opinion on the value of it since I didn't know what its capabilities were.

I know. My intent was not to "cross" you, but I just wanted to let him know that the link was only going to confuse him.

If it was another, intelligent hardware RAID solution, then that link would have been viable. All he needed was to get the driver.

But I've only seen a few FRAID attempts and they are much more involved than a SCSI module. Or the vendor only releases a kernel version-specific module.

I think you have offered a far more educated assessment of the relative value than I could have.

Well, I wasn't even trying to assert that. I know it seems I have an "agenda" against FRAID, and I readily admit I do. But it's for good reasons.

I don't particularly like MD either, but MD is much, much better than FRAID.

Craig White craigwhite@azapple.com wrote:

of course you are assuming facts not in evidence. If for example, he was trying to dual-boot with Windows and Windows had already set the drives up as fake raid... then he would probably have to work it through in this way to use a partition on the existing raid setup in some

manner

• and then my links may have been helpful.

Incorrect.

What I'm saying is that FRAID does _not_ have drivers like intelligent hardware RAID cards. They are typically embedded in the ATA subsystem (requiring a full kernel rebuild), or have other requirements other than just "building a SCSI module."

I of course wouldn't know this - I only have one system as dual-boot - my ancient Sony PictureBook laptop and am generally not a fan of dual-boot systems.

I've installed over 1,000 dual-boot systems in my time. I have _never_ gotten FRAID to work at all on them.

Now using MD and NT4-volumes (and, to a lesser extent, NT5-LDM) simultaneously, that's a different story. A crapload more manageable.

But I agree with you, dual-booting is a nightmare. Especially since Microsoft is currently "dorking around" with disk geometry in NT5.1SP2+ (XP SP2) and is breaking all sorts of things. They are using areas of Cylinder 0 (MBR cylinder)to store information on non-LDM disks.

"Bryan J. Smith" b.j.smith@ieee.org wrote:

Lastly, I've also not seen FRAID-5 supported yet either.

FYI, from the kernel 2.4 iswraid README:

While they may or may not be distinguishing features, iswraid also: * supports RAID0 (striping) over n-disk volumes; * supports RAID1E (mirroring with striping) over n-disk volumes---this is equivalent to RAID1 for 2-disk volumes and to RAID10 for 4-disk volumes; * supports multiple volumes per array ("Matrix RAID");

Again, no newer FRAID-5 support. I'd actually like to see how well Windows FRAID-5 works against software RAID-5 in Linux.

* deals with missing disks in a reasonable manner;

This one is my favorite. ;->

In other words, the fact that you have no intelligence local to the hardware is a major issue, one that software can't solve. I.e., you can't just hot-swap FRAID hardware, let alone if a device goes down, the kernel might panic.

Why? Because the "raw" individual drives are still what the kernel communicates with.

* can operate with volumes in degraded mode (unless instructed not to); * implements disk error thresholds; * tries to satisfy failed RAID1E reads using each failed disk's mirror.

Again, more subjective differences that could be an issue between the FRAID 16-bit BIOS and the OS -- especially when dual-booting.

Mark Belanger mark_belanger@ltx.com wrote:

I dont' know - how do I tell? I fired up a 3.5 install, it saw the disks, and I installed.

What disks did it see?

FRAID is just that, fake RAID. The OS sees the actual disks. You have to use a 100% software hack to trick the OS into organizing the disks differently.

What I've commonly seen is someone install Linux on a FRAID controller and install to the disks directly, _no_ understanding whatsoever of the FRAID organization.

So at next boot, you either can't boot, or the FRAID 16-bit Int13h disk services realizes that the FRAID organizaton has been _destroyed_ and just boots the "raw" disk. If you were dual-booting and had previously installed Windows, it's now _toasted_.

Again, support of the "FRAID organization" is required _in_addition_ to the "ATA/SATA" channels. The ICH5/6/7 ATA channel might be supported, but the kernel utterly ignores the FRAID organization.

You have to be very careful.

Creating a 100Meg files seems pretty good: time dd if=/dev/zero of=/var/tmp/blah bs=1024 count=100000 100000+0 records in 100000+0 records out

But what devices? Give me an output of "dmesg" and "df".

Now based on those devices, give me an output of "fdisk -l" on each.

We could also look at the /proc filesystem after that.