The last two filesystems are special; the first (/proc) is a special filesystem provided by the kernel as a way of providing information about the system to user programs. The information in the /proc filesystem is used in order to make utilities such as ps, top, xload, free, netstat, and so on work. Some of the "files" in /proc are really enormous (for example, /proc/kcore) but don't worry—all the information in the /proc filesystem is generated on-the-fly by the Linux kernel as you read it; no disk space is wasted. You can tell that they are not real files because, for example, root can't give them away with chown.

The final "filesystem" isn't, in fact, a filesystem at all; it is an entry that indicates a disk partition used as swap space. Swap partitions are used to implement virtual memory. Files can also be used for swap space. The names of the swap files go in the first column where the device name usually goes.

The two numeric columns on the right relate to the operation of the dump and fsck commands, respectively. The dump command compares the number in column five (the dump interval) with the number of days since that filesystem was last backed up so that it can inform the system administrator that the filesystem needs to be backed up. Other backup software—for example, Amanda—can also use this field for the same purpose. (Amanda can be found at the URL http://www.cs.umd.edu/projects/amanda/amanda.html .) Filesystems without a dump interval field are assumed to have a dump interval of zero, denoting "never dump." For more information, see the manual page for dump.

The sixth column is the fsck pass and indicates which filesystems can be checked in parallel at boot time. The root filesystem is always checked first, but after that, separate drives can be checked simultaneously, Linux being a multitasking operating system. There is no point, however, in checking two filesystems on the same hard drive at the same time, because this would result in lots of extra disk head movement and wasted time. All the filesystems that have the same pass number are checked in parallel, from 1 upward. Filesystems with a 0 or missing pass number (such as the floppy and CD-ROM drives) are not checked at all.

Creating New Filesystems

When you install Red Hat Linux, the installation process makes some new filesystems and sets the system up to use them. When you later come to set up new filesystems under Linux, you will be coming to it for the first time.

Many operating systems don't distinguish between the preparation of the device's surface to receive data (formatting) and the building of new filesystems. Linux does distinguish between the two, principally because only floppy disks need formatting in any case, and also because Linux offers as many as half a dozen different filesystems that can be created (on any block device). Separately providing the facility of formatting floppy disks in each of these programs would be poor design and would require you to learn a different way of doing it for each kind of new filesystem. The process of formatting floppy disks is dealt with separately (see the section "Floppy Disks," later in this chapter).

Filesystems are initially built by a program that opens the block device and writes some structural data to it so that, when the kernel tries to mount the filesystem, the device contains the image of a pristine filesystem. This means that both the kernel and the program used to make the filesystem must agree on the correct filesystem structure.

Linux provides a generic command, mkfs, that enables you to make a filesystem on a block device. In fact, because UNIX manages almost all resources with the same set of operations, mkfs can be used to generate a filesystem inside an ordinary file! Because this is unusual, mkfs asks for confirmation before proceeding. When this is done, you can even mount the resulting filesystem using the loop device (see the section "Mounting Filesystems on Files," later in this chapter).

Because of the tremendous variety of filesystems available, almost all the work of building the new filesystem is delegated to a separate program for each; however, the generic mkfs program provides a single interface for invoking them all. It's not uncommon to pass options to the top-level mkfs (for example, -V to make it show what commands it executes or -c to make it check the device for bad blocks). The generic mkfs program also enables you to pass options to the filesystem-specific mkfs. There are many of these filesystem-dependent options, but most of them have sensible defaults, and you normally would not want to change them. The only options you might want to pass to mke2fs, which builds ext2 filesystems, are -m and -i. The -m option specifies how much of the filesystem is reserved for root's use (for example, for working space when the system disk would otherwise have filled completely). The -i option is more rarely exercised and is used for setting the balance between inodes and disk blocks; it is related to the expected average file size. As stated previously, the defaults are reasonable for most purposes, so these options are used only in special circumstances:

# mkfs -t ext2 /dev/fd1

mke2fs 1.10, 24-Apr-97 for EXT2 FS 0.5b, 95/08/09

Linux ext2 filesystem format

Filesystem label=

360 inodes, 1440 blocks

72 blocks (5.00) reserved for the super user

First data block=1

Block size=1024 (log=0)

Fragment size=1024 (log=0)

1 block group

8192 blocks per group, 8192 fragments per group

360 inodes per group



Writing inode tables: done

Writing superblocks and filesystem accounting information: done

# mount -t ext2 /dev/fd1 /mnt/floppy

# ls -la /mnt/floppy

total 14

drwxr-xr-x   3 root     root         1024 Aug  1 19:49 .

drwxr-xr-x   7 root     root         1024 Jul  3 21:47 ..

drwxr-xr-x   2 root     root        12288 Aug  1 19:49 lost+found

# umount /mnt/floppy

Here, you see the creation and mounting of an ext2 filesystem on a floppy. The structure of the filesystem as specified by the program's defaults are shown. There is no volume label, and there are 4096 bytes (4KB) per inode (360 ¥ 4 = 1440). The block size is 1KB and 5 percent of the disk is reserved for root. These are the defaults (which are explained in the mke2fs manual page). After you have created a filesystem, you can use dumpe2fs to display information about an ext2 filesystem, but remember to pipe the result through a pager such as less because this output can be very long.

After creating the filesystem on this floppy, you can include it in the filesystem table by changing the existing line referring to a vfat filesystem on /dev/fd1 to the following:

/dev/fd1      /mnt/floppy    ext2   user,sync,errors=continue 0 0

The first three columns are the device, mount point, and filesystem type, as shown previously. The options column is more complex than previous ones. The user option indicates that users are allowed to mount this filesystem. The sync option indicates that programs writing to this filesystem wait while each write finishes, and only then continue. This might seem obvious, but it is not the normal state of affairs. The kernel normally manages filesystem writes in such a way as to provide high performance (data still gets written to the device of course, but it doesn't necessarily happen immediately). This is perfect for fixed devices such as hard disks, but for low-capacity removable devices such as floppy disks it's less beneficial. Normally, you write a few files to a floppy and then unmount it and take it away. The unmount operation must wait until all data has been written to the device before it can finish (and the disk can then be removed). Having to wait like this is off-putting, and there is always the risk that someone might copy a file to the floppy, wait for the disk light to go out, and remove it. With asynchronous writes, some buffered data might not have yet been written to disk. Hence, synchronous writes are safer for removable media.

The ext2 filesystem has a configurable strategy for errors. If an ext2 filesystem encounters an error (for example, a bad disk block) there are three possible responses to the error:

Remount the device read-only—For filesystems that contain mostly nonessential data (for example, /tmp, /var/tmp, or news spools), remounting the filesystem read-only so that it can be fixed with fsck is often the best choice.

Panic—Continuing regardless in the face of potentially corrupted system configuration files is unwise, so a kernel panic (that is, a controlled crash—or emergency landing, if you prefer) can sometimes be appropriate.

Ignore it—Causing a system shutdown if a floppy disk has a bad sector is a little excessive, so the continue option tells the kernel to "carry on regardless" in this situation. If this actually does happen, the best thing to do is to use the -c option of e2fsck, for example, with fsck -t ext2 -c /dev/fd1. This runs e2fsck, giving it the -c option, which invokes the command badblocks to test the device for bad disk blocks. After this is done, e2fsck does its best to recover from the situation.