• Aucun résultat trouvé

Patching Older Kernels

Dans le document LINUX RAID (Page 75-78)

Working with 2.0.X and 2.2.X kernels can be extremely confusing because of the lay-out and documentation for the available patches. Most people have a lot of trouble sifting through all the old and erroneous information relating to these kernel ver-sions and their RAID implementations. While RAID support is included with 2.0.X and 2.2.X series kernels, the most recent drivers are not distributed with the kernel source code, and patches should be applied when possible. There are also known problems with RAID-5 on 2.2 and 2.0 kernels, so if you want to use RAID-5, you should upgrade to at least a 2.4 kernel.

Kernel 2.2

When working with 2.2 series kernels, Istrongly recommend that you upgrade to the latest RAID code (0.90). The 0.90 code is available as a patch to the kernel and should be applied before any attempt to build new arrays. As a general principle, you should always be working with version 0.90 (or later) of the RAID code. You can examine the file.../linux/include/linux/md.hto determine which version of the RAID code is present on 2.0 and 2.2 series kernels. Version information is located near the beginning of the file:

[...]

#define MD_MAJOR_VERSION 0

#define MD_MINOR_VERSION 36

#define MD_PATCHLEVEL_VERSION 6 [...]

This 2.2 kernel has version 0.36.6 of the RAID subsystem; therefore, a patch should be applied. If .../linux/include/linux/md.h is either empty or missing, your kernel is probably already patched to version 0.90. Instead, check the file .../linux/include/

linux/raid/md.hfor the version information. Note the extra subdirectory namedraid in the path. As the size of RAID code grew, a subdirectory was created to better orga-nize its components.

Patches for the 2.2 kernel are available at http://people.redhat.com/mingo/raid-patches/. A patch for the most recent sublevel release of 2.2, as well as patches for a few prior 2.2 sublevel releases, should be available at this site. Grab the one for the specific sublevel release with which you are working. If a patch for that particular sublevel release is unavailable, Irecommend upgrading to the most recent 2.2 release and using the matching RAID patch.

For example, if you are working with kernel 2.2.20, download the patch http://

people.redhat.com/mingo/raid-patches/raid-2.2.20-A0. Apply the raid-2.2.20-A0

patch to your 2.2.20 kernel, using the-p1 flag to indicate that you are in theroot directory of the source tree:

# cd /usr/src/linux-2.2.20

# patch -s -p1 < /usr/src/patches/raid-2.2.20-A0

Passing the -sflag topatchinvokes quiet mode. Ifpatch is successful, no output it returned. If an error was encountered, thenpatchwill output a list of reject files that contain more detailed information about the errors. If you encounter errors, it’s pos-sible that a faulty, or untested, patch was released. Try throttling your kernel back-ward one revision (to 2.2.19, in this case), download a new patch, and reapply it.

When the problem is eventually corrected, you can safely upgrade and repatch. You can, alternatively, examine the reject files and attempt to manually fix problems that patchencounters. If you choose not to use quiet mode, thenpatchwill return a list of files that have been successfully patched, in addition to the names of any reject files generated.

Remember that new patch files and kernels are released often, so the filenames used throughout this book may differ slightly from the ones you encounter when down-loading patches. The locations of important kernel patches will also inevitably change as kernel maintainers change employers and as subsystems change maintainers.

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 forBYTEmagazine that explains the implications of kernel source trees and applying patches to clean ker-nels (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).

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 automati-cally activate arrays when the system boots. Originally, RAID devices were started either manually at the command line or by system initialization (rc) scripts.

Autodetectionexamines 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 dis-abled 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 con-fusing. Patch files are no longer maintained, older utilities are needed to manage devices, and both patches and tools are kept in an area ofkernel.orgthat is not main-tained. 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 recom-mend 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 ker-nel, 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 compila-tion 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 sub-system is now ready for compilation. Enable RAID features under the Floppy, IDE, and other block devices submenu during configuration (see Figure 3-4). First, enable Multiple Devices Support (CONFIG_BLK_DEV_MD) and then any RAID you need. It is safe to leave Autodetect RAID Partitions (CONFIG_AUTODETECT_RAID) activated, but leave Translucent Mode (CONFIG_MD_TRANSLUCENT) and Hierarchical Storage Manage-ment Support (CONFIG_MD_HSM) disabled (see the previous section, “Kernel 2.2”).

Dans le document LINUX RAID (Page 75-78)