Managing RAID on Linux - Derek Vadala [39]
When working with kernel patches, it's a good idea to apply them to a clean, unpatched kernel. Moshe Bar has written an excellent article for BYTE magazine that explains the implications of kernel source trees and applying patches to clean kernels (http://www.byte.com/documents/s=2470/byt1012259408690/0204_bar.html).
As in 2.4 kernels, RAID support must be enabled during kernel configuration of 2.2 kernels. During this earlier phase of RAID development, the RAID subsystem did not have its own submenu. Instead, RAID configuration options were put in the Block Devices submenu. Simply enable Multiple Devices Driver Support (CONFIG_BLK_DEV_MD) and at least one RAID level (see Figure 3-3).
Figure 3-3. Enable support for Multiple Devices and at least one RAID level.
If you plan to experiment with different RAID levels, simply enable all of them. Under 2.2, the various RAID levels can also be built as loadable kernel modules. You might also notice some other options that provide additional features. The first, Autodetect RAID Partitions (CONFIG_AUTODETECT_RAID), allows the kernel to automatically activate arrays when the system boots. Originally, RAID devices were started either manually at the command line or by system initialization (rc) scripts.
Autodetection examines the RAID superblock (see The RAID Superblock section, later in this chapter) on hard disks to determine which disks are members of arrays and then to activate them. It is safe to leave RAID autodetection enabled. On newer kernels, autodetection is standard and therefore no longer appears as an option.
Translucent Mode (CONFIG_MD_TRANSLUCENT) and Hierarchical Storage Management Support (CONFIG_MD_HSM) were experimental options that appeared in the 2.2 kernel, but were never developed. They no longer appear in later kernels and should be disabled when working with any kernel that advertises them as features.
Kernel 2.0
As I've mentioned several times earlier in this chapter, kernels earlier than 2.2 are best not used for software RAID. Software RAID under 2.0 kernels is especially confusing. Patch files are no longer maintained, older utilities are needed to manage devices, and both patches and tools are kept in an area of kernel.org that is not maintained. So it's best to avoid using software RAID with 2.0 kernels, unless there are extenuating circumstances. If you must work with a 2.0 kernel, I strongly recommend upgrading to the latest kernel prior to using software RAID. Usable patches are available only for kernels newer than 2.0.35. It's a bad idea to even attempt using a kernel older than this.
Download the most recent 2.0 kernel patch from ftp://ftp.kernel.org/pub/linux/daemons/raid/alpha/. Notice that this directory contains files for both 2.0 and 2.2 kernels. Use only 2.0 kernel patches from this directory. (Patches for 2.2 should be obtained as described in the previous section, Kernel 2.2.)
Note, though, that if you were using kernel 2.0.39, you would need to download raid0145-19990824-2.0.37.gz. As of this writing, no patches specific to kernels later than 2.0.37 were available. The 2.0.37 patch should apply without severe problems. But if you find yourself in a situation in which a patch doesn't match your kernel sublevel version, or if you encounter problems while patching or compiling a 2.0 kernel, you should work with the kernel that matches the most recent patch. At worst, you will be forced to use a kernel that is one or two sublevel revisions behind, and eventually a newer patch will be released and you can upgrade.
To be on the safe side, I'm going to unroll a 2.0.37 kernel and apply this patch, rather than risk using a 2.0.39 kernel that might present problems during compilation or at runtime.
# cd /usr/src/linux-2.0.37
# patch -s -p1 < /usr/src/patches/raid0145-19990824-2.0.37
With 2.0.37, the patch returns no errors. A 2.0 kernel using the 0.90 RAID subsystem is now ready