Managing RAID on Linux - Derek Vadala [81]
Be extremely wary of binary-only modules. Forward compatibility is never guaranteed, and support is available only from your vendor, instead of the vast community of open source developers. And you can't fix problems that might arise on your own because you don't have access to the source code.
The availability of user-space tools—that is, tools that are run after the operating system has loaded—is also a consideration. After all, the potential high-availability features of RAID aren't much good if you have to restart your system to run BIOS-level configuration tools to perform essential administrative tasks such as creating a new array, managing failed disks, and adding new spare disks. So, when choosing a controller, look for a vendor that provides open source drivers, preferably integrated into the current stable kernel tree, as well as some user-space management tools.
So far, I have not found any vendor-provided, open source management tools. However, I have been told by at least one vendor that they have plans to open source their command line and GUI management tools, and I think this move will start a trend among other manufacturers. In past years, there have been a few open source projects that provided user-space support for various RAID controllers, but at the time of this writing, they are all unmaintained.
Preparing Controllers and Disks
It's vitally important that all disks used in any hardware array are identical (see the Matched drives section in Chapter 2) and that all have the same firmware revision. There are documented cases in which non-uniform firmware revisions have led to data corruption. Furthermore, it's important to use the latest firmware revision for both controllers and disks and, in some cases, even for the BIOS on your motherboard. In general, it's a good idea to upgrade all system components to the most up-to-date firmware before placing any system in production.
Computer equipment, especially disk controllers and hard disks, tends to sit in warehouses for several months before it is shipped to resellers and end users. That usually means that by the time you purchase your equipment, there has been at least one firmware, or controller BIOS, release correcting important bugs that often affect interoperability or performance.
For example, a controller I was working with during the course of this writing wouldn't work consistently using recently purchased SCSI hard disks that were a couple of firmware revisions behind. Hard disks often ship with older firmware, and that doesn't usually affect systems that use standalone disks. However, since hard disk firmware controls environmental factors such as rotation speed and thermal calibration, using disks with varying firmware in an array can be catastrophic. To function optimally, RAID controllers require that all disks be calibrated the same way. Variations in firmware can foil the entire process.
Nearly every vendor provides simple utilities that perform firmware and BIOS upgrades. These utilities are available from vendor web sites and FTP servers. Unfortunately, very few component hardware vendors provide an easy way for Linux users to apply these upgrades without depending on Microsoft products.
* * *
Warning
Almost all vendors distribute their upgrades and upgrade utilities in ZIP archives. You will need the unzip utility to decompress them. It's also common for some of these vendors to distribute self-extracting ZIP archives with the .exe extension. These archives are not self-extracting under Linux, but you can use the unzip utility to manually decompress the file's contents.
* * *
That's because all of these utilities (with a very small number of exceptions) are designed to run under a DOS-compatible operating system. That means you will need to provide your own bootable DOS disks, onto which you can copy firmware and BIOS upgrades and their associated utilities.