Managing RAID on Linux - Derek Vadala [124]
One exception to this rule is systems that have add-on ATA channels via PCI cards. If an entire card is removed, or fails, the detection order will change. Let's say that a system has two ATA/100 PCI controllers, each with two channels. The first card, containing two disks that are assigned /dev/hde and /dev/hdf, fails. Naturally, users and applications will no longer be able to access data on those disks. The problem is further complicated when the system reboots and assigns device names. Because the first PCI controller isn't detected this time, the disks on the second controller now have their device names shifted down two positions. So while the disks on the second controller were originally assigned /dev/hdg and /dev/hdh, they will now be assigned /dev/hde and /dev/hdf. Not only will applications that are looking for data on disks connected to the failed controller complain, but filesystems associated with /dev/hdg and /dev/hdh will now look for their disks in the wrong place, causing another series of problems. Luckily, the advent of filesystem labels and UUID information helped fix some of the issues associated with device naming because arrays can now be started using parameters stored on disk, rather than based on their physical connections. Filesystems can be mounted in the same manner.
SCSI operates in almost the same way, except that the first four device names are not tied to onboard controllers. Although any onboard SCSI controllers will be detected first by the BIOS and Linux, the first device names are not reserved for them. On a motherboard with onboard SCSI and a PCI SCSI controller, the onboard controller is assigned a value of 0 and the PCI controller a value of 1. If the PCI controller has four disks connected and the onboard controller has no disks connected, then the disks on the PCI controllers are assigned /dev/sda through /dev/sdd. If two disks are added to the onboard controller, they will be assigned /dev/sda and /dev/sdb. The disks connected to the PCI controller would then shift to /dev/sdc through /dev/sdf. It's best to disable onboard controllers that you are not using to avoid any confusion or potential problems with device naming.
I advise you to consider using the Device Filesystem (Devfs) to help solve some of these issues. Devfs uses a device-naming scheme similar to the one used in many commercial Unix operating systems, such as Solaris. Devices' names are based on controller number and SCSI identification number, instead of simple device lettering. So a disk failure doesn't affect device naming within a single I/O channel. But failure or removal of an entire controller still has the same effect. Consult the Devfs FAQ at http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html.
Configuring Hard Disk Parameters
Hard disks, like most computer components, are shipped with certain configurations that manufacturers have determined are ideal for the largest denomination of users. Unfortunately, these default settings often mean that disks are shipped with configurations that make them compatible with the largest number of consumer desktops, as opposed to making them perform as fast as possible. Luckily, many of these parameters can be tuned to meet specific system needs. With the help of system-tuning utilities, these parameters can be modified to increase overall array and standalone disk performance.
* * *
Warning
The performance tips covered in this section are meant to be performed on individual disks, not arrays. However, it is essential that you apply any changes uniformly to each component disk in your arrays. Tuning one or more disks and failing to tune others will result in poor, and probably bizarre, performance.
* * *
I strongly recommend that anyone who isn't already familiar with the basic tactics of performance tuning first carefully read http://linuxperf.nl.linux.org/baseline.html. It outlines quite a number of ideas that are essential to successful systems management and stability. There are also many other articles available from http://linuxperf.nl.linux.org/