Well promise RAID is software raid as well. Using the included 2.6xx raid functionality will at least not hurt your performance anymore than using the Promise software raid drivers. Depending on the nature of Promise's drivers(which i have heard mainly negative things) you will get better performance using the built in RAID from Linux.

Steven Moix - Axianet.ch wrote:

Hello,

In some weeks I'm going to reinstall some old RedHat9 based servers with Promise FastTrak TX2000 "semi-hardware" RAID1 controllers. I just tried to install CentOS 4.0 on a computer with a spare card and as usual both HDD attached to the RAID1 controller are seen separately by the installer because the specific driver for the TX2000 wasn't loaded. Nothing new here, it was always like this on every distro as far as I know.

Now I googeled a bit and have some questions:

1. In some forums I could read that the FastTrak series in RAID mode

wasn't supported anymore in the 2.6 kernel (was PDCRAID module in the later 2.4 kernels). Quoted apparently from the linux kernel mailing list:

...

...

In 2.6, Promise software RAID support does not exist. In conversations with Promise, we all agreed to encourage and support the standard Linux RAID, md.

So does this mean that I have to use software RAID in linux if I don't want to load the drivers provided by Promise (see question 2)?

2. On the other hand Promise provides the partial source code for their

driver, but there is a silly problem with this...I want to install my OS directly on the RAID array :) So I guess that I would have to:

• Install CentOS on another computer, compile the driver provided by

Promise, make a driver disk (don't ask me how).

• Boot CentOS on the server with the controller and type "linux dd" to

load this driver disk.

• Pray and correct bugs for the next 2 weeks.

Is this the right way to go?

Any feedback with FastTrak TX2000 or TX4000 controllers would be very welcome, let me know which solution you choosed.

Thanks Steven

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Sat, 2005-05-21 at 11:22 +0200, Steven Moix - Axianet.ch wrote:

Hello, In some weeks I'm going to reinstall some old RedHat9 based servers with Promise FastTrak TX2000 "semi-hardware" RAID1 controllers. I just tried to install CentOS 4.0 on a computer with a spare card and as usual both HDD attached to the RAID1 controller are seen separately by the installer because the specific driver for the TX2000 wasn't loaded. Nothing new here, it was always like this on every distro as far as I know.

The problem with "FRAID" (Fake/Free RAID -- even the, as you called it, "semi-hardware" ones with DRAM) will always be that there is 3rd party licensed code. And that code will never become GPL or even open sourced in any way because not only does Promise (or HPT, or SilImage for that matter) not own it, but the 3rd party that does would see their sales go to 0 if they didn't keep it under proprietary licensure.

It's the same issue with _any_ "software-driven" hardware product. The code is from the same 2-3 companies that the 1,000s of manufacturers actually license from.

As you have discovered, there is the "clean-room" ataraid.c software RAID logic and the individual hptraid.c, pdcraid,c and silraid.c FRAID interface modules. The idea is that there is this "single" core logic for all FRAID cards in ataraid.c, and then the independent hptraid.c, pdcraid.c and silraid.c for each of the FRAID card vendor's products.

I'm sure it's getting dropped because it's basically impossible to keep up with all the little changes in the interfaces or RAID logic of the various FRAID code as well as specific FRAID card instances.

Furthermore, one change in how Windows XP handles disk geometry -- which has been a major issue I've run into as of post-SP1, SP2 and post-SP2 hot-fixes -- when dual-booting means the interface driver could actually destroy the fake array organization easily. The only way I see to address this is if _everyone_ (Linux, FRAID cards, any other disk organization/modification programs) used the LDM Disk Label (aka "Dynamic Disk") as the "standard," which allows a lot of these details to be stored in the disk label (exact disk geometry, journal of changes, etc...).

Reality: FRAID is always slower than Linux LVM/MD or NT LDM. Other than boot-time Int13h services, it offers nothing.