Promise FastTrak TX2000 under Linux

In my current job, I had to make myself familiar with a couple of entry-level to midrange PCI RAID controllers.

One of them was the Promise FastTrak TX2000 that we've been selling as part of Windows machines for quite some time now, with positive response.

In Linux 2.4, the situation is somewhat different.
Especially, the RAID functionality is clearly software-based and, in contrast to the Windows implementation of the RAID software, the Linux port lags miles behind the standard.

There are two ways to access the RAID volume created using the Promise RAID: there's an open-source set of hardware-specific drivers that comes with the vanilla kernel, and there's a proprietary driver tarball from Promise.

The situation described here pertains to the Linux kernel versions around 2.4.18 to 2.4.22 and was observed in the summer of 2003.

The open-source way

There's a plain IDE driver (no RAID functionality) and there's the Ataraid driver adding some rudimentaty RAID functionality on top of that. The history of these drivers picked up some spin around 2.4.20.

In Linux, the controller is frequently referred to by the name of its chip: PDC20271. Its plain IDE driver is contained in a file called

drivers/ide/pdc202xx.c
  or
drivers/ide/pci/pdc202xx_new.c

The respective Menuconfig entry is under ATA/IDE/MFM/RLL..., please note that the dependent "FastTrak feature" option is not necessary (irrelevant for this chip).

The Ataraid driver (contained in drivers/ide/raid/) has a hardware-specific sub-module called pdcraid.c. You'll find these two under ATA/IDE/MFM/RLL..., "Support for IDE RAID controllers", "Support for Promise RAID".

The Ataraid driver (contained in drivers/ide/raid/) has a hardware-specific sub-module called pdcraid.c.

The pdcraid.c has a bug in the array detection routine. With IDE disks where C*H*S != capacity, it miscalculates the offset of the RAID superblock (at the start of the last track). I have corrected that bug, here's a patch - I just hope that I got the formula right. The key part of the patch is the single line containing the formula:

lba = ideinfo->capacity - ideinfo->sect;

It might also be specific to a particular (newer) firmware revision.

To apply the patch, CD into the directory with your pdcraid.c:

 cd /usr/src/linux/drivers/ide/raid/

and run the patch program:

  patch -p0 </path/to/the/downloaded/file/PDC20271.patch

The proprietary way

The proprietary Promise driver is modular-only - probably due to the fact that it consists of an open-source wrapper and a binary-only library. Which means that if you want to boot from a Promise RAID volume, you need to use a customized initial ramdisk (initrd) to load the module before you can remount the root to the RAID volume.

That might be a pain. Fortunately, the driver can be monolithized. No need for an initrd anymore. After applying this monolithization package, it appears under "SCSI support -> SCSI low-level drivers" in Menuconfig.

Monolithic or not, you'll need to disable detection of the PDC20271 as a plain IDE controller. You need to disable detection of any IDE controllers above your onboard integrated channels. This is done using a series of additional kernel parameters - e.g. in lilo.conf, you need to add

 append="ide2=0 ide3=0 ... ide9=0"

The proprietary HW+RAID driver emulates a SCSI device - hence the need to disable native detection of its IDE hardware.

As with any BIOS-emulated disk device used with Lilo, it might come in handy to specify that

disk=/dev/sda
     bios=0x80

Conclusion

In my practical user experience, both ways provide a shaky solution that pretty much fails to deliver the traditional RAID advantages: performance, fault-tolerance and background recovery operations.
The drivers are only any good as a way to access a Windows partition from Linux. While the Windows software by Promise seems really good, it's a waste of money to purchase the FastTrak TX2000 exclusively for Linux.

The Linux software RAID is well documented and I'm not going to discuss it here.

One last note: if you ever wanted to reuse a drive that once was a member in a Promise RAID, you might want to purge it clean from the remnants of the RAID setup.
E.g., the MBR might be modified to save some space at the end of the drive for the RAID superblock, and there could be other Promise-proprietary hacks in the MBR too, which might confuse partitioning and formatting tools and operating systems' filesystem drivers.

Theoretically it should be enough to clean the MBR:

 dd if=/dev/zero of=/dev/your_device bs=512 count=1

But it's not a bad idea to wipe a larger block clean, which should take the first partition's boot sector with it:

 dd if=/dev/zero of=/dev/your_device bs=1k count=10000

Also, if you wanted to re-use such a Promise-tainted drive in another Promise array, it might be a good idea to remove the old RAID superblock itself, to prevent the RAID controller (its drivers, really) from detecting the long defunct array.
The superblock is located at the start of the last track on the drive. Now it might be a bit of a problem to decide what this really means, as the logical CHS is bogus with modern drives and it may not match the total capacity reported by that same drive. The total capacity, if different from logical C*H*S, might be equal to the physical C*H*S, but the track size might also be different, and I don't really know which one is correct.
The procedure that has worked for me is to calculate the offset of the start of the last track from logical CHS. This may be lower than or equal to the offset actually chosen by the Promise controller based on the LBA capacity and track size reported. Next, I write the rest of the disk starting from this offset with zeroes from /dev/zero.
The aforementioned parameters can be obtained from
 /proc/ide/device_name/geometry
and
 /proc/ide/device_name/capacity

I've written a perl script to do the cleanup for you.

Last update: 7 October 2003