There are a variety of tools that are in the “computer person’s” toolbox—lots of them are niche tools that are great for certain types of situations. But sometimes, the tool doesn’t exist (or, it exists, but is so esoteric that maybe you cannot find it). What do you do then?

In today’s strange situation, I was faced with a RAID 5 array done in hardware with a Promise SX4000 card. This card has 4 IDE ports and does some strange hybrid software/hardware RAID. It has drivers for Microsoft Windows and a 2.4 version of the Linux kernel. There is a “partial source code” implementation that supposedly supports 2.6, but it doesn’t build and I don’t know if bringing it up-to-date would be useful on modern kernels. Effectively, this piece of crap isn’t supported under Linux.

Alright, then. The array had 4 200 GB drives attached to it, which (in RAID 5) yields 600 GB of usable space for partitions, a filesystem, whatever. Because the computer has to boot from it, the BIOS on the card permits reading the RAID array in real mode (that’s the mode of the processor that the computer starts executing in, and is the same mode that DOS uses to run). So, my first thought was to run in real mode using FreeDOS and pull the data off the drive that way. It’s an NTFS drive, and there are NTFS drivers for DOS. Well, that didn’t work, because the USB mass storage drivers for DOS failed to function—they did not support the USB chipset in the computer—and so that was a failed idea. This also meant that I’d be unable to do something like take a bit-for-bit disk image and send that to a USB-attached hard disk.

I tried seeing if there was some sort of way to make the thing show up in Linux. This is one situation where having a “int13″ disk driver would make a LOT of sense. It would be slow, but it’d work since the BIOS of the RAID card hooks real mode Interrupt 13 and makes it possible to read the array. One could then ‘dd’ the image to a drive that Linux does support, so as to recover the data from the filesystem contained within the image. Well, that, too, was a no-go.

After several attempts at doing this various different ways, all strange variations of ideas coming off the top of my head, I remembered that I had a Windows 2000 disc from way back when, and wondered if that would work. Indeed, it did. The drivers supported Windows 2000, and Cygwin provides a ‘dd’ implementation that lets you take bitcopies of drives just like you can under a real UNIX or UNIX-like system, like Linux. So, that saved the day, and now there’s a 600 GB drive image sitting on a 1 TB drive. This is a big YAY.

However, my life would have been a lot simpler had one of the following things been true:

• The Promise SX4000 adapter had native support in Linux. This is a fault of the company, Promise Technology. They should’ve released a driver as fully open-source back when they made the hardware so that it would still be in the mainline kernel today, being maintained. If anyone from Promise sees this, now would be a good time to forward-port that driver for the piece of hardware y’all have forgotten about so that your once-customers can use it. At least one person I know is throwing the damned thing away because y’all couldn’t be bothered to support his use of it.
• The Linux kernel supported accessing disks via real-mode interfaces. This is probably unfeasible, actually, because trying to do things in real-mode from a protected mode operating system is more than a small technical feat. One could observe this with Windows 95 and its real-mode disk access for devices it saw but didn’t support directly.
• The RAID adapter presented a standard IDE interface to the computer system. In other words, it should have appeared to the system as a single 600 GB IDE attached drive. It’d still have a BIOS hook so that large arrays could be accessed and booted from, and it’d still have an optional second interface to present to the operating system so that it could monitor the RAID array’s health and the like, but not as part of the drive access commands. If you make RAID controllers, you should make them play well with yesterday’s, today’s, and tomorrow’s operating systems, so that people can use them until they die. By not doing that you are making your users throw these things away before they die. Additionally, if you aren’t going to provide drivers for the information-sharing part of the board, provide specs at least so that we can write them for our favorite operating systems.

Today’s experience has taught me one thing: If you want RAID, do it in software on a platform that you’ll know you can access in five years. Linux 2.4 does not boot on a lot of today’s modern hardware, but Linux software RAID is supported very nicely since then. Software RAID may be a pinch slower than hardware RAID, but if the hardware RAID controller requires drivers that make you run a whole installation of an operating system just to pull data off of it (in this case the operating system on the array is utter crap, and could not be accessed, but the data is fine), it’s not worth having.

Even Windows software RAID support (their “dynamic disks”) is better than a hardware RAID solution. I think that the support for accessing it from other operating systems is still experimental for some of its featureset, but at least it can be done. And if one must use hardware RAID, make damn sure the disk array can (at the very least) be put into a mode to present itself as a single IDE or SATA attached hard drive. Ideally, that would be its default and probably only mode.