Improving Disk Performance

How to get the most out of your hard disks

by Roderick W. Smith Tuesday, November 15th, 2005
...
...
Filesystem Choice

Beyond adjusting the way the kernel talks to your hard disks, you can choose which filesystem or filesystems your system uses. Unfortunately, picking a filesystem for optimal performance isn’t an easy task. Too many variables exist that affect performance, such as disk throughput, disk head seek speeds, overall system load, how full the filesystem is, and whether you’re accessing large or small files. A few generalizations can be drawn, though:

*Journaling filesystems are preferable. Journaling filesystems (ext3fs, ReiserFS, JFS, and XFS) maintain a journal, or log of pending changes. Maintaining the journal slightly degrades performance, but greatly speeds recovery after a power failure or other uncontrolled shutdown. Most journaling filesystems include more advanced features than do non-journaling filesystems (such as ext2fs), which partly or completely counteracts the extra effort the journal requires to maintain. Overall, a journaling filesystem is a big improvement, particularly if you want to minimize boot times after a problem shutdown. An exception is small filesystems (such as /boot, if it’s on a separate partition), on which the journal consumes too high a percentage of disk space to be worth its while.

*Small files work best with ReiserFS. If a partition holds many small files, look into ReiserFS. Although it might or might not perform any better than other filesystems, ReiserFS is more efficient at packing small files onto the disk. The result is that you can fit more small files on a disk.

*ext2fs and ext3fs are dependable on all platforms. Fortunately, all the major Linux filesystems (ext2fs, ext3fs, ReiserFS, XFS, and JFS) are reliable on x86 systems. On other platforms, one or more of these may be sluggish or unreliable. If in doubt, stick with ext2fs or ext3fs; these are the most likely to be speedy and reliable.

If getting the absolute best speed out of your filesystem is important, you may need to perform some tests, ideally using the hard disk and applications you intend to use. For a typical single-computer desktop or even small server installation, such tests are likely to consume so much time that they aren’t worthwhile. If you’re deploying hundreds of identical desktop systems, though, it might be worth running a few tests to see how different filesystems cope with the sorts of tasks your systems will be performing.

Filesystem Layout
In addition to filesystem choice, filesystem layout can affect performance. Two factors are important to consider when designing a filesystem layout:
*Seek times. When Linux accesses data from different partitions on a single disk, the disk head must move (or seek) from one area of the disk to another. This action takes time, so if your disk layout is such that data from the start and end of the disk must be frequently accessed, performance will be degraded compared to a layout in which frequently accessed data lie close together.
*Disk throughput. As noted earlier, disk throughput varies from one part of a disk to another. As a general rule, earlier parts of the disk (partitions in low-numbered cylinders) perform better than do latter parts of the disk. Thus, putting frequently accessed data at the start of the disk generally makes sense.
Typically, the best performance can be achieved by placing the most-used partitions, such as partitions for /usr, /home, and swap space, in the middle of the disk. Partitions that are seldom accessed, such as /boot or a partition holding an emergency Linux installation, are best placed in the peripheral regions of the disk.
Figure One illustrates a good single-disk configuration. The assumption is that most accesses involve /usr, /home,, or swap space, with progressively less frequent accesses for partitions further from these. Such a layout will minimize disk seek times and therefore maximize performance. Of course, different systems might have different access patterns, so Figure One might be an excellent configuration for one system but poor for another.
Figure One: An optimized disk configuration places frequently accessed data near the center of the disk

In multi-disk systems, try to spread your access across disks. For instance, in a multi-boot configuration, don’t devote one disk entirely to Linux and the other disk entirely to the other OS. Splitting both OSs across both disks will improve performance for both OSs.

In a Linux-only configuration with multiple disks, put both commonly used and rarely used partitions on both disks. If /usr is on one disk and /home is on another, then a pattern of use that entails accessing files in both directories will require no head seeks to move between those two partitions (although of course there may be head seeks within each partition).

Advanced configurations take advantage of Linux’s support for Redundant Array of Independent Disks (RAID). This technology enables you to split a single virtual partition across two or more physical disks. This can be done to improve data security (in case one disk fails, a copy will exist on another disk), to improve performance (by spreading access across multiple disks), or both. Although RAID configuration is too complex to cover in this column, it’s well worth investigating if you need to get the most out of your disks.
Roderick W. Smith is the author or co-author of over a dozen books, including Linux in a Windows World and Linux Power Tools. He can be reached at
class="emailaddress">rodsmith@rodsbooks.com.
Roderick W. Smith is the author or coauthor of more than a dozen books, including Linux in a Windows World and Linux Power Tools. He can be reached at rodsmith@rodsbooks.com.