In this section I will refer you to a few programs available to examine, adjust the parameters of, and measure performance of, filesystems. I am no expert on these topics, so you will have to do further reading as interested.

tune2fs [options] devicefile

The tune2fs program allows you to examine filesystem parameters stored in the superblock and to adjust some of them. To start with, let's examine the superblock of a disk partition using tune2fs -l :

A few of the parameters that you might be interested in are the filesystem label and the UUID, both of which can be used to mount the filesystem, the block size,  the size of inode, and filesystem creation dates. You can use tune2fs to change the Label (tune2fs -L) and/or the UUID (tune2fs -U), both of which are familiar.

You may also notice a parameter called filesystem error behavior in the superblock. This dictates what should happen when an error is detected on the filesystem. This filesystem is marked continue, which means the error will be reported by the kernel (using syslog), but the filesystem will be left in service. There are two other possible values for this parameter:

remount-ro  -  remount the filesystem read-only when an error is detected

panic  -  cause a kernel panic when an error is detected.

Changing this setting will, of course, severely restrict system functionality(!) In all cases, when a filesystem error is detected, the filesystem will be checked at the next reboot (or, at least, this is what the documentation says.) 

The other set of parameters you may want to adjust using tune2fs are those that govern when a filesystem is checked. As you know, the reason to use a journaled filesystem is to avoid the lengthy filesystem-checking procedure when the filesystem is reattached. At boot, the system customarily performed a filesystem check. Normaly, "clean" filesystems are skipped. Since journaled filesystems are always "clean", this meant that a full check was never performed on a journaled filesystem. Until recently, it was considered wise to force a full check every so often. This full check was performed even if fsck was given a clean filesystem, if either of the two following metrics dictated:

• a maximum number of days of operation. This metric is implemented using the three superblock parameters last checked, last mount, and check interval. When fsck is run, if the current date is more than check interval past the last checked date, the filesystem is fully checked even if the filesystem is marked "clean". This metric can be disabled by setting check interval to 0.

• a maximum number of mounts. This metric is implemented using the superblock parameters mount count and maximum mount count. At mount, mount count is incremented. When fsck is run, if the mount count exceeds maximum mount count, a check is forced. This parameter can be disabled by setting maximum mount count to -1.

Recently, our systems filesystems have both of these metrics disabled at installation. This evident faith in the integrity of the journaling filesystem is curious in the light of this warning, which is twice repeated in the documentation of tune2fs(1):

Here are a few options of tune2fs to adjust these parameters:

-c max-mount-count  -  set the maximum mount count. If the filesystem as installed is checked based on mount count and you reboot your system often, you may want to increase max-mount-count or set it to -1 to use the time parameter for checking instead. Conversely, if you have suspicions about one of your filesystems, you can force its checking at the next reboot by setting the maximum mount count to less than the mount count. (If your filesystem currently has a max-mount-count, it is probably better to force a check by adjusting the mount-count (below) instead.)

-C mount-count - set the mount count. To force a check, set this to more than the maximum-mount-count.

-i interval[dwm] - set the time interval between checks. The suffix d (days), w (weeks) or m (months) may be added. days is the default.

Using tune2fs to add default mount options

As discussed in a previous section, the acl and user_xattr mount options are added by default on filesystems created by the installer. You can add these to your newly-created filesystem as well (to avoid the necessity of adding them to the mount command) by using the tune2fs command. The syntax is the same as it would be for running a mount command: tune2fs -o opt,opt1,opt2,... device

Examining (and modifying) a filesystem using debugfs [-w] devicefile

debugfs is an interactive filesystem debugger. It can be used to examine or modify a filesystem. Normally, the filesystem is opened in read-only mode (examine). The -w option enables read-write mode. I would suggest that only unmounted filesystems should be opened in read-write mode.

One useful feature of debugfs is to examine a file's complete inode. Use the stat function. You can also mark a filesystem dirty or clean, or dump raw blocks to disk. If you are interested in the internals of an ext2/3 filesystem, debugfs can help you investigate.

Of course, changing a filesystem is only for the expert. Feel free to use debugfs without the -w option though and look around as you like.

Monitoring disk health using smartd

A subsystem named smartd is provided on linux to monitor/report disk health. Many devices today are smart-compatible; however, this service is not started by default. To inquire about its results, use the smartctl command.

Examining disk parameters using hdparm device

When used with the devicefile of your disk itself (e.g., /dev/hda), hdparm can be used to examine a drive's parameters (-i or -I), to time I/O (-t or -T) and to examine, and even change, disk parameters. Try hdparm -I /dev/hda (or /dev/sda) to see information about your drive.