You probably created filesystems and swap space when you first installed Linux (most distributions help you do the basics). Here is a chance to fine-tune these resources. Most of the time, you do these things shortly after installing your operating system, before you start loading up your disks with fun stuff. But occasionally you will want to change a running system, for example, to add a new device or perhaps upgrade the swap space when you upgrade your RAM.
To Unix systems, a filesystem is some device (such as a hard drive, floppy, or CD-ROM) that is formatted to store files. Filesystems can be found on hard drives, floppies, CD-ROMs, and other storage media that permit random access. (A tape allows only sequential access, and therefore cannot contain a filesystem per se.)
The exact format and means by which files are stored is not important; the system provides a common interface for all filesystem types it recognizes. Under Linux, filesystem types include the Third Extended filesystem, or ext3fs, which you probably use to store Linux files; the Reiser filesystem, another popular filesystem for storing Linux files; the VFAT filesystem, which allows files on Windows 95/98/ME partitions and floppies to be accessed under Linux (as well as Windows NT/2000/XP partitions if they are FAT-formatted); and several others, including the ISO 9660 filesystem used by CD-ROM.
Each filesystem type has a very different underlying format for storing data. However, when you access any filesystem under Linux, the system presents the data as files arranged into a hierarchy of directories, along with owner and group IDs, permission bits, and the other characteristics with which you’re familiar.
In fact, information on file ownership, permissions, and so forth is provided only by filesystem types that are meant to be used for storing Linux files. For filesystem types that don’t store this information, the kernel drivers used to access these filesystems “fake” the information. For example, the MS-DOS filesystem has no concept of file ownership; therefore, all files are presented as if they were owned by root. This way, above a certain level, all filesystem types look alike, and each file has certain attributes associated with it. Whether this data is actually used in the underlying filesystem is another matter altogether.
As the system administrator, you need to know how to create filesystems should you want to store Linux files on a floppy or add additional filesystems to your hard drives. You also need to know how to use the various tools to check and maintain filesystems should data corruption occur. Also, you must know the commands and files used to access filesystems—for example, those on floppy or CD-ROM.
Table 10-1 lists the filesystem types supported by the Linux kernel as of Version 2.6.5. New filesystem types are always being added to the system, and experimental drivers for several filesystems not listed here are available. To find out what filesystem types your kernel supports, look at the file /proc/filesystems. You can select which filesystem types to support when building your kernel; see "Kernel configuration: make config" in Chapter 18.
Table 10-1. Linux filesystem types
Filesystem | Type | Description |
---|---|---|
Second Extended filesystem | ext2 | Used to be the most common Linux filesystem, but is slowly being made obsolete by the Reiser and Third Extended filesystems |
Reiser filesystem | reiserfs | A journaling filesystem for Linux |
Third Extended filesystem | ext3 | Another journaling filesystem for Linux that is downward-compatible with ext2 |
JFS | jfs | IBM’s implementation of a journaled filesystem for Linux; an alternative to ext3 and reiserfs |
Network File System (NFS) | NFS | Allows access to remote files on network |
UMSDOS filesystem | umsdos | Installs Linux on an MS-DOS partition |
DOS-FAT filesystem | msdos | Accesses MS-DOS files |
VFAT filesystem | vfat | Accesses Windows 95/98/ME files |
NT filesystem | ntfs | Accesses Windows NT/2000/XP files |
/proc filesystem | proc | Provides process information for ps |
ISO 9660 filesystem | iso9660 | |
UDF filesystem | udf | The most modern CD-ROM filesystem |
SMB filesystem | smbfs | Accesses files from a Windows server over the network |
Coda filesystem | coda | An advanced network filesystem, similar to NFS |
Cifs filesystem | cifs | The Common Internet File System, Microsoft’s suggestion for an SMB successor; supported by Windows 2000, 2003, and XP, as well as the Samba server |
Each filesystem type has its own attributes and limitations; for example, the MS-DOS filesystem restricts filenames to eight characters plus a three-character extension and should be used only to access existing MS-DOS floppies or partitions. For most of your work with Linux, you’ll use the Second or Third Extended (ext2 or ext3) filesystem, which were developed primarily for Linux and support 256-character filenames, a 32-terabyte maximum filesystem size, and a slew of other goodies, or you will use the Reiser (reiserfs ). Earlier Linux systems used the Extended filesystem (no longer supported) and the Minix filesystem. (The Minix filesystem was originally used for several reasons. First of all, Linux was originally cross-compiled under Minix. Also, Linus was quite familiar with the Minix filesystem, and it was straightforward to implement in the original kernels.) Some other obscure filesystems available in older Linux kernels are no longer supported.
The main difference between the Second Extended filesystem on the one hand and the Reiser and the Third Extended filesystem on the other hand is that the latter two are journaled. Journaling is an advanced technique that keeps track of the changes made to a filesystem, making it much easier (and faster!) to restore a corrupted filesystem (e.g., after a system crash or a power failure). Another journaled filesystem is IBM’s Journaling File System, JFS.
You will rarely need the ROM filesystem , which is very small, does not support write operations, and is meant to be used in ramdisks at system configuration, startup time, or even in EPROMS. Also in this group is the Cram filesystem, which is used for ROMs as well and compresses its contents. This is primarily meant for embedded devices, where space is at a premium.
The UMSDOS filesystem is used to install Linux under a private directory of an existing MS-DOS partition. This is a good way for new users to try out Linux without repartitioning, at the expense of poorer performance. The DOS-FAT filesystem, on the other hand, is used to access MS-DOS files directly. Files on partitions created with Windows 95 or 98 can be accessed via the VFAT filesystem, whereas the NTFS filesystem lets you access Windows NT filesystems . The HPFS filesystem is used to access the OS/2 filesystem.
/proc is a virtual filesystem; that is, no actual disk space is associated with it. See "The /proc Filesystem,” later in this chapter.[*]
The ISO9660 filesystem (previously known as the High Sierra Filesystem and abbreviated hsfs on other Unix systems) is used by most CD-ROMs. Like MS-DOS, this filesystem type restricts filename length and stores only limited information about each file. However, most CD-ROMs provide the Rock Ridge Extensions to ISO 9660, which allow the kernel filesystem driver to assign long filenames, ownerships, and permissions to each file. The net result is that accessing an ISO 9660 CD-ROM under MS-DOS gives you 8.3-format filenames, but under Linux gives you the “true,” complete filenames.
In addition, Linux now supports the Microsoft Joliet extensions to ISO 9660, which can handle long filenames made up of Unicode characters. This is not widely used now but may become valuable in the future because Unicode has been accepted internationally as the standard for encoding characters of scripts worldwide.
Linux also supports UDF, a filesystem that is meant for use with CD-RWs and DVDs.
Next, we have many filesystem types for other platforms. Linux supports the formats that are popular on those platforms in order to allow dual-booting and other interoperation. The systems in question include UFS, EFS, BFS, XFS, System V, and BeOS. If you have filesystems created in one of these formats under a foreign operating system, you’ll be able to access the files from Linux.
Finally, there is a slew of filesystems for accessing data on partitions; these are created by operating systems other than the DOS and Unix families. Those filesystems support the Acorn Disk Filing System (ADFS), the Amiga OS filesystems (no floppy disk support except on Amigas), the Apple Mac HFS, and the QNX4 filesystem. Most of the specialized filesystems are useful only on certain hardware architectures; for instance, you won’t have hard disks formatted with the Amiga FFS filesystem in an Intel machine. If you need one of those drivers, please read the information that comes with them; some are only in an experimental state.
Besides these filesystems that are used to access local hard disks, there are also network filesystems for accessing remote resources. We talk about those to some extent later.
Finally, there are specialty filesystems , such as those that store the data in RAM instead of on the hard disk (and consequentially are much faster, but also lose all their data when the computer is powered off), and those that provide access to kernel objects and kernel data.
In order to access any filesystem under Linux, you must mount it on a certain directory. This makes the files on the filesystem appear as though they reside in the given directory, allowing you to access them.
Before we tell you how to mount filesystems, we should also mention that some distributions come with automounting setups that require you to simply load a diskette or CD into the respective drive and access it just as you would on other platforms. There are times, however, when everybody needs to know how to mount and unmount media directly. (We cover how to set up automounting yourself later.)
The mount command is used to do this and
usually must be executed as root. (As we’ll see
later, ordinary users can use mount if the device is listed in the
/etc/fstab file and the entry
has the user
option.) The format
of this command is:
mount -t type device mount-point
where type
is the type name of the
filesystem as given in Table 10-1,
device
is the physical device where the
filesystem resides (the device file in /dev), and
mount-point
is the directory on which to
mount the filesystem. You have to create the directory before
issuing mount.
For example, if you have a Third Extended filesystem on the partition /dev/hda2 and wish to mount it on the directory /mnt, first create the directory if it does not already exist and then use the command:
mount -t ext3 /dev/hda2 /mnt
If all goes well, you should be able to access the filesystem under /mnt. Likewise, to mount a floppy that was created on a Windows system and therefore is in DOS format, you use the command:
mount -t msdos /dev/fd0 /mnt
This makes the files available on an
MS-DOS-format floppy under /mnt. Note that using msdos
means that you use the old DOS
format that is limited to filenames of eight plus three characters.
If you use vfat
instead, you get
the newer format that was introduced with Windows 95. Of course, the
floppy or hard disk needs to be written with that format as
well.
There are many options for the mount command, which can be specified with
the -o
switch. For example, the
MS-DOS and ISO 9660
filesystems support “autoconversion” of text files from
MS-DOS format (which contain
CR-LF at the end of each line) to Unix format
(which contain merely a newline at the end of each line). Using a
command such as:
mount -o conv=auto -t msdos /dev/fd0 /mnt
turns on this conversion for files that don’t have a filename extension that could be associated with a binary file (such as .exe, .bin, and so forth).
One common option to mount is -o ro (or, equivalently, -r), which mounts the filesystem as read-only. All write access to such a filesystem is met with a “permission denied” error. Mounting a filesystem as read-only is necessary for media such as CD-ROMs that are nonwritable. You can successfully mount a CD-ROM without the -r option, but you’ll get the following annoying warning message:
mount: block device /dev/cdrom is write-protected, mounting read-only
Use a command such as:
mount -t iso9660 -r /dev/cdrom /mnt
instead. This is also necessary if you are trying to mount a floppy that has the write-protect tab in place.
The mount manual page lists
all available mounting options. Not all are of immediate interest,
but you might have a need for some of them, someday. A useful
variant of using mount is
mount -a, which mounts all filesystems listed
in /etc/fstab except those
marked with the noauto
option.
The inverse of mounting a filesystem is, naturally, unmounting it. Unmounting a filesystem has two effects: it synchronizes the system’s buffers with the actual contents of the filesystem on disk, and it makes the filesystem no longer available from its mount point. You are then free to mount another filesystem on that mount point.
Unmounting is done with the umount command (note that the first “n” is missing from the word “unmount”). For example:
umount /dev/fd0
unmounts the filesystem on /dev/fd0. Similarly, to unmount whatever filesystem is currently mounted on a particular directory, use a command such as:
umount /mnt
It is important to note that removable media, including floppies and CD-ROMs, should not be removed from the drive or swapped for another disk while mounted. This causes the system’s information on the device to be out of sync with what’s actually there and could lead to no end of trouble. Whenever you want to switch a floppy or CD-ROM, unmount it first using the umount command, insert the new disk, and then remount the device. Of course, with a CD-ROM or a write-protected floppy, there is no way the device itself can get out of sync, but you could run into other problems. For example, some CD-ROM drives won’t let you eject the disk until it is unmounted.
Reads and writes to filesystems on floppies are buffered in memory, like they are for hard drives. This means that when you read or write data to a floppy, there may not be any immediate drive activity. The system handles I/O on the floppy asynchronously and reads or writes data only when absolutely necessary. So if you copy a small file to a floppy, but the drive light doesn’t come on, don’t panic; the data will be written eventually. You can use the sync command to force the system to write all filesystem buffers to disk, causing a physical write of any buffered data. Unmounting a filesystem makes this happen as well.
If you wish to allow mortal users to mount and unmount certain
devices, you have two options. The first option is to include the
user
option for the device in
/etc/fstab (described later in
this section). This allows any user to use the mount and umount command for a given device. Another
option is to use one of the mount frontends available for Linux.
These programs run setuid as
root and allow ordinary users to mount certain
devices. In general, you wouldn’t want normal users
mounting and unmounting a hard drive partition, but you could
be more lenient about the use of CD-ROM and
floppy drives on your system.
Quite a few things can go wrong when attempting to mount a filesystem. Unfortunately, the mount command will give you the same error message in response to a number of problems:
mount: wrong fs type, /dev/cdrom already mounted, /mnt busy, or other error
wrong fs type
is simple
enough: this means that you may have specified the wrong type to
mount. If you don’t specify a type,
mount tries to guess the filesystem type from
the superblock (this works only for minix,
ext2, ext3, and
iso9660). If mount still
cannot determine the type of the filesystem, it tries all the types
for which drivers are included in the kernel (as listed in /proc/filesystems). If this still does
not lead to success, mount
fails.
device
already mounted
means just that: the
device is already mounted on another directory. You can find out
what devices are mounted, and where, using the
mount command with no arguments:
rutabaga# mount
/dev/hda2 on / type ext3 (rw)
/dev/hda3 on /windows type vfat (rw)
/dev/cdrom on /cdrom type iso9660 (ro)
/proc on /proc type proc (rw,none)
Here, we see two hard drive partitions, one of type ext3 and the other of type
vfat, a CD-ROM mounted on
/cdrom, and the /proc filesystem. The last field of each
line (for example, (rw)
) lists
the options under which the filesystem is mounted. More on these
soon. Note that the CD-ROM device is mounted in
/cdrom. If you use your
CD-ROM often, it’s convenient to create a special
directory such as /cdrom and
mount the device there. /mnt is
generally used to temporarily mount filesystems such as
floppies.
The error mount-point
busy
is rather odd. Essentially, it means
some activity is taking place under
mount-point
that prevents you from
mounting a filesystem there. Usually, this means that an open file
is under this directory, or some process has its current working
directory beneath mount-point
. When using
mount, be sure your root shell is not within
mount-point
; do a cd
/ to get to the top-level directory. Or, another
filesystem could be mounted with the same
mount-point
. Use mount with no arguments to find
out.
Of course, other error
isn’t very helpful. There are several other cases in which mount could fail. If the filesystem in
question has data or media errors of some kind, mount may report it is unable to read the
filesystem’s superblock, which is (under
Unix-like filesystems) the portion of the filesystem that stores
information on the files and attributes for the filesystem as a
whole. If you attempt to mount a CD-ROM or floppy
drive and there’s no CD-ROM or floppy in the
drive, you will receive an error message such as
mount: /dev/cdrom is not a valid block device
Floppies are especially prone to physical defects (more so than you might initially think), and CD-ROMs suffer from dust, scratches, and fingerprints, as well as being inserted upside-down. (If you attempt to mount your Stan Rogers CD as ISO 9660 format, you will likely run into similar problems.)
Also, be sure the mount point you’re trying to use (such as /mnt) exists. If not, you can simply create it with the mkdir command.
If you have problems mounting or accessing a filesystem, data on the filesystem may be corrupt. Several tools help repair certain filesystem types under Linux; see "Checking and Repairing Filesystems,” later in this chapter.
The system automatically mounts several filesystems when the system boots. This is handled by the file /etc/fstab, which includes an entry for each filesystem that should be mounted at boot time. Each line in this file is of the following format:
device
mount-point
type
options
Here, device
,
mount-point
, and
type
are equivalent to their meanings in
the mount command, and
options
is a comma-separated list of
options to use with the -o
switch
to mount.
A sample /etc/fstab is shown here:
# device directory type options /dev/hda2 / ext3 defaults /dev/hda3 /windows vfat defaults /dev/cdrom /cdrom iso9660 ro /proc /proc proc none /dev/hda1 none swap sw
The last line of this file specifies a swap partition. This is described in "Managing Swap Space,” later in this chapter.
The mount(8) manual page lists the
possible values for options
; if you wish
to specify more than one option, you can list them with separating
commas and no whitespace, as in the following examples:
/dev/cdrom /cdrom iso9660 ro,user
The user
option allows
users other than root to mount the filesystem.
If this option is present, a user can execute a command such
as:
mount /cdrom
to mount the device. Note that if you specify only a device or mount point (not both) to mount, it looks up the device or mount point in /etc/fstab and mounts the device with the parameters given there. This allows you to mount devices listed in /etc/fstab with ease.
The option defaults
should
be used for most filesystems; it enables a number of other options,
such as rw
(read-write access),
async
(buffer I/O to the
filesystem in memory asynchronously), and so forth. Unless you have
a specific need to modify one of these parameters, use defaults
for most filesystems, and
ro
for read-only devices such as
CD-ROMs. Another potentially useful option is
umask
, which lets you set the
default mask for the permission bits, something that is especially
useful with some foreign filesystems.
The command mount -a will mount all filesystems listed in /etc/fstab. This command is executed at boot time by one of the scripts found in /etc/rc.d, such as rc.sysinit (or wherever your distribution stores its configuration files). This way, all filesystems listed in /etc/fstab will be available when the system starts up; your hard drive partitions, CD-ROM drive, and so on will all be mounted.
There is an exception to this: the root filesystem. The root filesystem, mounted on /, usually contains the file /etc/fstab as well as the scripts in /etc/rc.d. In order for these to be available, the kernel itself must mount the root filesystem directly at boot time. The device containing the root filesystem is coded into the kernel image and can be altered using the rdev command (see "Using a Boot Floppy" in Chapter 17). While the system boots, the kernel attempts to mount this device as the root filesystem, trying several filesystem types in succession. If at boot time the kernel prints an error message, such as
VFS: Unable to mount root fs
one of the following has happened:
The root device coded into the kernel is incorrect.
The kernel does not have support compiled in for the filesystem type of the root device. (See "Building the Kernel" in Chapter 18 for more details. This is usually relevant only if you build your own kernel.)
The root device is corrupt in some way.
In any of these cases, the kernel can’t proceed and panics. See "What to Do in an Emergency" in Chapter 27 for clues on what to do in this situation. If filesystem corruption is the problem, this can usually be repaired; see "Checking and Repairing Filesystems,” later in this chapter.
A filesystem does not need to be listed in /etc/fstab in order to be mounted, but it
does need to be listed there in order to be mounted “automatically”
by mount -a, or to use the user
mount option.
If you need to access a lot of different filesystems , especially networked ones, you might be interested in a special feature in the Linux kernel: the automounter. This is a combination of kernel functionality, a daemon, and some configuration files that automatically detect when somebody wants to access a certain filesystem and mounts the filesystem transparently. When the filesystem is not used for some time, the automounter automatically unmounts it in order to save resources such as memory and network throughput.
If you want to use the automounter, you first need to turn this feature on when building your kernel. (See "Building the Kernel" in Chapter 18 for more details.) You will also need to enable the NFS option.
Next, you need to start the automount daemon. In order to check whether you have automount installed, look for the directory /usr/lib/autofs. If it is not there, you will need to get the autofs package from your friendly Linux archive and compile and install it according to the instructions.
Note that there are two versions of automount support: Version 3 and Version 4. Version 3 is the one still contained in most distributions, so that’s what we describe here.
You can automount filesystems wherever you like, but for simplicity’s sake, we will assume here that you want to automount all filesystems below one directory that we will call /automount here. If you want your automount points to be scattered over your filesystem, you will need to use multiple automount daemons.
If you have compiled the autofs package yourself, it might be a good idea to start by copying the sample configuration files that you can find in the sample directory and adapting them to your needs. To do this, copy the files sample/auto.master and sample/auto.misc into the /etc directory, and the file sample/rc.autofs under the name autofs wherever your distribution stores its boot scripts. We’ll assume here that you use /etc/init.d. (Unfortunately, some distributions do not provide those sample files, even if they do carry the autofs package. In that case, it might still be a good idea to download the original package.)
The first configuration file to edit is /etc/auto.master. This lists all the directories (the so-called mount points) below which the automounter should mount partitions. Because we have decided to use only one partition in this chapter’s example, we will need to make only one entry here. The file could look like this:
/automount /etc/auto.misc
This file consists of lines with two entries each, separated by whitespace. The first entry specifies the mount point, and the second entry names a so-called map file that specifies how and where to mount the devices or partitions to be automounted. You need one such map file for each mount point.
In our case, the file /etc/auto.misc looks like the following:
cd -fstype=iso9660,ro :/dev/scd0 floppy -fstype=auto :/dev/fd0
Again, this file consists of one-line entries, each specifying one particular device or partition to be automounted. The lines have two mandatory and one optional field, separated by whitespaces. The first value is mandatory and specifies the directory onto which the device or partition of this entry is automounted. This value is appended to the mount point; thus, the CD-ROM will be automounted onto /automount/cd.
The second value is optional and specifies flags to be used for the mount operation. These are equivalent to those for the mount command itself, with the exception that the type is specified with the option -fstype=instead of -t.
Finally, the third value specifies the partition or device to
be mounted. In our case, we specify the first SCSI
CD-ROM drive and the first floppy drive, respectively. The
colon in front of the entry is mandatory; it separates the host part
from the device/directory part, just as with
mount. Because those two devices are on a local
machine, there is nothing to the left of the colon. If we wanted to
automount the directory sources
from the NFS server sourcemaster
, we would specify something
like the following:
sources -fstype=nfs,soft sourcemaster:/sources
Please notice that the /etc/auto.misc file must not be executable; when in doubt, issue the following command:
tigger# chmod a-x /etc/auto.misc
After editing the configuration files to reflect your system, you can start the automount daemon by issuing the following command (replace the path with the path that suits your system):
tigger# /etc/init.d/autofs start
Because this command is very taciturn, you should check whether the automounter has really started. One way to do this is to issue:
tigger# /etc/init.d/autofs status
but it is difficult to determine from the output whether the automounter is really running. Your best bet, therefore, is to check whether the automount process exists:
tigger# ps aux | grep automount
If this command shows the automount process, everything should be all right. If it doesn’t, you need to check your configuration files again. It could also be the case that the necessary kernel support is not available: either the automount support is not in your kernel, or you have compiled it as a module but not installed this module. If the latter is the case, you can fix the problem by issuing
tigger# modprobe autofs
If that doesn’t work, you need to use:
tigger# modprobe autofs4
instead.[*] When your automounter works to your satisfaction, you might want to put the modprobe call as well as the autofs call in one of your system’s startup configuration files, such as /etc/rc.local, /etc/init.d/boot.local, or whatever your distribution uses.
If everything is set up correctly, all you need to do is access some directory below the mount point, and the automounter will mount the appropriate device or partition for you. For example, if you type
tigger$ ls /automount/cd
the automounter will automatically mount the CD-ROM so that ls can list its contents. The only difference between normal and automounting is that with automounting you will notice a slight delay before the output comes.
To conserve resources, the automounter unmounts a partition or device if it has not been accessed for a certain amount of time (the default is five minutes).
The automounter supports a number of advanced options; for example, you do not need to read the map table from a file but can also access system databases or even have the automounter run a program and use this program’s output as the mapping data. See the manpages for autofs(5) and automount(8) for further details.
You can create a filesystem using the mkfs command. Creating a filesystem is analogous to formatting a partition or floppy, allowing it to store files.
Each filesystem type has its own mkfs command associated with it—for example, MS-DOS filesystems may be created using mkfs.msdos, Third Extended filesystems using mkfs.ext3, and so on. The program mkfs itself is a frontend that creates a filesystem of any type by executing the appropriate version of mkfs for that type.
When you installed Linux, you may have created filesystems by
hand using a command such as mke2fs, which,
despite the name, can create both ext2 and
ext3 filesystems. (If not, the installation
software created the filesystems for you.) The programs are the same
(and on many systems, one is a symbolic link to the other), but the
mkfs.fs-type
filename makes it easier for mkfs to execute
the appropriate filesystem-type-specific program. If you don’t have
the mkfs frontend, you can use
mke2fs or mkfs.ext2
directly.
Assuming that you’re using the mkfs frontend, you can create a filesystem using this command:
mkfs -t type device
where type
is the type of
filesystem to create, given in Table 10-1, and
device
is the device on which to create
the filesystem (such as /dev/fd0 for a floppy).
For example, to create an ext2 filesystem on a floppy (it does not make much sense to use journaling on a floppy disk, which is why we don’t use ext3 here), you use this command:
mkfs -t ext2 /dev/fd0
You could create an MS-DOS floppy using -t msdos instead.
We can now mount the floppy (as described in the previous section), copy files to it, and so forth. Remember to unmount the floppy before removing it from the drive.
Creating a filesystem deletes all data on the corresponding physical device (floppy, hard drive partition, whatever). mkfs usually does not prompt you before creating a filesystem, so be absolutely sure you know what you’re doing.
Creating a filesystem on a hard drive partition is done as
shown earlier, except that you use the partition name, such as
/dev/hda2, as the
device
. Don’t try to create a filesystem
on a device such as /dev/hda.
This refers to the entire drive, not just a single partition on the
drive. You can create partitions using fdisk,
as described in “Editing /etc/fstab” in Chapter 2.
You should be especially careful when creating filesystems on
hard drive partitions. Be absolutely sure that the
device
and
size
arguments are correct. If you enter
the wrong device, you could end up destroying
the data on your current filesystems, and if you specify the wrong
size, you could overwrite data on other
partitions. Be sure that size
corresponds
to the partition size as reported by Linux fdisk.
When creating filesystems on floppies, it’s usually best to do a low-level format first. This lays down the sector and track information on the floppy so that its size can be automatically detected using the devices /dev/fd0 or /dev/fd1. One way to do a low-level format is with the MS-DOS FORMAT command; another way is with the Linux program fdformat. (Debian users should use superformat instead.) For example, to format the floppy in the first floppy drive, use the command
rutabaga# fdformat /dev/fd0
Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.
Formatting ... done
Verifying ... done
Using the -n
option with fdformat will skip the verification
step.
Each filesystem-specific version of mkfs
supports several options you might find useful. Most types support
the -c
option, which causes the
physical media to be checked for bad blocks while creating the
filesystem. If bad blocks are found, they are marked and avoided
when writing data to the filesystem. In order to use these
type-specific options, include them after the -t
type
option
to mkfs, as follows:
mkfs -ttype
-cdevice blocks
To determine what options are available, see the manual page for the type-specific version of mkfs. (For example, for the Second Extended filesystem, see mke2fs.)
You may not have all available type-specific versions of mkfs installed. If this is the case, mkfs will fail when you try to create a filesystem of a type for which you have no mkfs.<type>. Many filesystem types supported by Linux have a corresponding mkfs.<type> available somewhere.
If you run into trouble using mkfs, it’s possible that Linux is having problems accessing the physical device. In the case of a floppy, this might just mean a bad floppy. In the case of a hard drive, it could be more serious; for example, the disk device driver in the kernel might be having problems reading your drive. This could be a hardware problem or a simple matter of your drive geometry being specified incorrectly. See the manual pages for the various versions of mkfs, and read the sections in Chapter 2 on troubleshooting installation problems. They apply equally here.[*]
It is sometimes necessary to check your Linux filesystems for consistency and to repair them if there are any errors or if you lose data. Such errors commonly result from a system crash or loss of power, making the kernel unable to sync the filesystem buffer cache with the contents of the disk. In most cases, such errors are relatively minor. However, if the system were to crash while writing a large file, that file might be lost and the blocks associated with it marked as “in use,” when in fact no file entry is corresponding to them. In other cases, errors can be caused by accidentally writing data directly to the hard drive device (such as /dev/hda), or to one of the partitions.
The program fsck is used to check filesystems and correct any problems. Like mkfs, fsck is a frontend for a filesystem-type-specific fsck.type, such as fsck.ext2 for Second Extended filesystems. (As with mkfs.ext2, fsck.ext2 is a symbolic link to e2fsck, either of which you can execute directly if the fsck frontend is not installed.)
Use of fsck is quite simple; the format of the command is:
fsck -t type device
where type
is the type of
filesystem to repair, as given in Table 10-1, and
device
is the device (drive partition or
floppy) on which the filesystem resides.
For example, to check an ext3 filesystem on /dev/hda2, you use:
rutabaga#fsck -t ext3 /dev/hda2
fsck 1.34 (25-Jul-2003) /dev/hda2 is mounted. Do you really want to continue (y/n)?y
/dev/hda2 was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts. Pass 5: Checking group summary information. Free blocks count wrong for group 3 (3331, counted=3396). FIXED Free blocks count wrong for group 4 (1983, counted=2597). FIXED Free blocks count wrong (29643, counted=30341). FIXED Inode bitmap differences: -8280. FIXED Free inodes count wrong for group #4 (1405, counted=1406). FIXED Free inodes count wrong (34522, counted=34523). FIXED /dev/hda2: ***** FILE SYSTEM WAS MODIFIED ***** /dev/hda2: ***** REBOOT LINUX ***** /dev/hda2: 13285/47808 files, 160875/191216 blocks
First of all, note that the system asks for confirmation before checking a mounted filesystem. If any errors are found and corrected while using fsck, you’ll have to reboot the system if the filesystem is mounted. This is because the changes made by fsck may not be propagated back to the system’s internal knowledge of the filesystem layout. In general, it’s not a good idea to check mounted filesystems.
As we can see, several problems were found and corrected, and because this filesystem was mounted, the system informed us that the machine should be rebooted.
How can you check filesystems without mounting them? With the exception of the root filesystem, you can simply umount any filesystems before running fsck on them. The root filesystem, however, can’t be unmounted while running the system. One way to check your root filesystem while it’s unmounted is to use a boot/root floppy combination, such as the installation floppies used by your Linux distribution. This way, the root filesystem is contained on a floppy, the root filesystem (on your hard drive) remains unmounted, and you can check the hard drive root filesystem from there. See "What to Do in an Emergency" in Chapter 27 for more details about this.
Another way to check the root filesystem is to mount it as
read-only . This can be done using the option ro
from the LILO boot prompt (see "Specifying boot-time
options" in Chapter
17). However, other parts of your system configuration (for
example, the programs executed by /etc/init at boot time) may require write
access to the root filesystem, so you can’t boot the system normally
or these programs will fail. To boot the system with the root
filesystem mounted as read-only, you might want to boot the system
into single-user mode as well (using the boot option single
). This prevents additional system
configuration at boot time; you can then check the root filesystem
and reboot the system normally. To do this in GRUB, you would edit
the command line in the GRUB screen interface by adding the ro
option.
To cause the root filesystem to be mounted as read-only, you
can either use the ro
boot
option, or use rdev to set the read-only flag
in the kernel image itself.
Many Linux systems automatically check the filesystems at boot time. This is usually done by executing fsck from /etc/rc.d/boot.rootfsck for the root filesystem and /etc/rc.d/boot.localfs (filenames may vary from distribution to distribution). When this is done, the system usually mounts the root filesystem initially as read-only, runs fsck to check it, and then runs the command:
mount -w -o remount /
The -o remount option causes the given filesystem to be remounted with the new parameters; the -w option (equivalent to -o rw) causes the filesystem to be mounted as read-write. The net result is that the root filesystem is remounted with read-write access.
When fsck is executed at boot time, it checks all filesystems other than root before they are mounted. Once fsck completes, the other filesystems are mounted using mount. Check out the files in /etc/rc.d, especially rc.sysinit (if present on your system), to see how this is done. If you want to disable this feature on your system, comment out the lines in the appropriate /etc/rc.d file that executes fsck.
You can pass options to the type-specific fsck. Most types support the option -a, which automatically confirms any prompts that fsck.type may display; -c, which does bad-block checking, as with mkfs; and -v, which prints verbose information during the check operation. These options should be given after the -t type argument to fsck, as in
fsck -ttype
-vdevice
to run fsck with verbose output.
See the manual pages for fsck and e2fsck for more information.
Not all filesystem types supported by Linux have a fsck variant available. To check and repair MS-DOS filesystems , you should use a tool under MS-DOS, such as the Norton Utilities, to accomplish this task. You should be able to find versions of fsck for the Second and Third Extended filesystem, Reiser filesystem JFS, and Minix filesystem.[*]
In "What to Do in an Emergency" in Chapter 27, we provide additional information on checking filesystems and recovering from disaster. fsck will by no means catch and repair every error to your filesystems, but most common problems should be handled. If you delete an important file, there is currently no easy way to recover it--fsck can’t do that for you. There is work under way to provide an “undelete” utility in the Second Extended filesystem. Be sure to keep backups, or use rm -i, which always prompts you before deleting a file.
Linux has supported encrypted file systems since at least
Version 2.2. However, due to export regulations regarding software
containing cryptographic algorithms, this feature had to be
distributed as a kernel patch, available from http://www.kernelipatcheskerneli .org/ (note the i
for international, which indicates that
the server was located outside the United States). This site is now
no longer maintained.
In kernel Version 2.4, the kerneli patches were no longer actively maintained. The preferred method to encrypt filesystems was loop-aes (http://loop-aes.sourceforge.net/), which could be built as a kernel module, restricted itself to disk encryption with AES, and was more actively maintained.[*]
The 2.6 kernel series saw the end of the kerneli crypto framework, as a group of kernel developers created a new framework from scratch. This framework has been since integrated into the vanilla (Linus) kernel. This text restricts itself to the 2.6 kernel, although the user-space tools have not changed their interfaces much. For instance, all losetup commands work on the kerneli kernels, but the mount options may be different.
Encrypted filesystem support works by using something called a transformed loopback block device (you may already know loopback devices from mounting CD-ROM ISO image files to access their contents).
To this end, you need to enable Device Drivers Loopback device support in the kernel’s configuration, as well as Cryptoloop support in the same section.
Cryptoloop uses the cryptographic API of a v2.6 kernel, which you can enable in Cryptographic options. Usually, it is sufficient to build everything (ciphers, compression algorithms, and digests) as modules, which in newer kernels is also the default. You do not need the Testing module.
You build and install the kernel as you would any other. On reboot, if you compiled Cryptoloop as a module, use modprobe cryptoloop to load it into the kernel.
The final thing is to check for a
util-linux package that can work with this
kernel’s cryptographic API. This package contains a number of
system administration commands for working with the kernel
cryptographic support. Unfortunately, as of this writing, the
necessary patches had not been applied to the latest release of
util-linux. Many distributions ship patched
versions, though. Please check whether cryptoapi
is supported in the
documentation that comes with your util-linux
package. If the losetup command
(described in the next section) fails with an invalid argument
error, the API probably is not in the distribution. In this case,
compile it yourself after applying the patches as detailed in the
Cryptoloop-HOWTO (http://www.tldp.org/HOWTO/Cryptoloop-HOWTO/).
Encrypted filesystems can be created either on top of a whole partition, or with a regular file as the storage space. This is similar to setting up swap space. However, in order to mask which blocks have been written to, you should initialize the file or partition with random data instead of zeroes — that is, use:
dd if=/dev/urandom of=file-or-partition
bs=1k count=size-in-kb
Omit the count
argument when overwriting a
partition, and ignore the resulting “device full” error.
Once the backing store is initialized, a loop device can be created on it using:
losetup -ecipher
/dev/loop0file-or-partition
Check /proc/crypto for the list of available ciphers of the running kernel.
You will be prompted for a passphrase once. You are not requested to retype the passphrase. This passphrase needs to have enough randomness to frustrate dictionary attacks. We recommend generating a random key for a 128-bit cipher through the following command:
head -c16 /dev/random | mimencode
Replace -c16 with -c32 for a 256-bit cipher. Naturally, these passphrases are hard to remember. After all, they are pure randomness. Write them down on a piece of paper stored far away from the computer (e.g., in your purse).
When the command returns successfully, anything written to /dev/loop0 will now be transparently encrypted with the chosen cipher and written to the backing store.
Now create a filesystem on /dev/loop0 as you would for any other partition. As an example, use mke2fs -j to create an ext3 filesystem. Once created, you can try mounting it using
mount -t ext3 /dev/loop0 mount-point
Write a text file into the encrypted filesystem and try to find the contents in the backing store, for example, using grep. Because they are encrypted, the search should fail.
After unmounting the filesystem with
umount/dev/loop0
,
do not forget to tear down the loop device again, using
losetup
-d/dev/loop0
.
Of course, setting up loopback devices and manually mounting them each time you need to access them is kind of tedious. Thankfully, you can make mount do all the work in setting up a loopback device.
Just add
-oencryption=cipher
to the mount command, like
this:
mount -t ext3 -oencryption=cipher file-or-partition mount-point
encryption=cipher
also works in the options column of /etc/fstab, so you can allow users to
mount and unmount their own encrypted filesystems.
When using encrypted filesystems, you should be aware of a few issues:
Mounted filesystems can be read by anyone, given appropriate permissions; they are not visible just to the user who created them. Because of this, encrypted filesystems should not be kept mounted when they are not used.
You cannot change the passphrase. It is hashed into the key used to encrypt everything. If you are brave, there is one workaround: set up two loop devices with losetup. Use the same encrypted filesystem as backing store for both, but supply the first one, say /dev/loop0, with the old passphrase, while giving the second one, say /dev/loop1, the new passphrase. Double-check that you can mount both (one after the other, not both at the same time). Remember you are only asked for the new passphrase once. Unmount them again; this was only to be on the safe side.
Now, use dd to copy over data from the first loop device to the second one, like this:
dd if=/dev/loop0 of=/dev/loop1 bs=4k
The block size (bs=parameter) should match the kernel’s page size, or the block size of the physical device, whichever is larger. This reads a block using the old passphrase and immediately writes it using the new passphrase. Better pray for no power outages while this is running, or buy a UPS.
Using the double loopback device trick, you can also change the cipher used to encrypt the data.
The weak link in the system is really your passphrase. A cryptographic algorithm with a 256-bit key is no good if that key is hashed from a guessable passphrase. English text has about 1.3 bits of randomness (also called entropy) per character. So you’d need to type in a sentence about 200 characters long to get the full security of the cipher. On the other hand, using the mimencode-dev-random trick we suggested earlier, you need only type in about 40 characters, albeit pure random ones.
[*] Note that the /proc filesystem under Linux is not the same format as the /proc filesystem under SVR4 (say, Solaris 2.x). Under SVR4, each running process has a single “file” entry in /proc, which can be opened and treated with certain ioctl() calls to obtain process information. On the contrary, Linux provides most of its information in /proc through read() and write() requests.
[*] We cover the modprobe command in “Loadable Device Drivers” in Chapter 18.
[*] Also, the procedure for making an ISO 9660 filesystem for a CD-ROM is more complicated than simply formatting a filesystem and copying files. See Chapter 9 and the CD-Writing HOWTO for more details.
[*] Actually, some distributions carry a command called dosfsck/fsck.msdos, but using this is not really recommended.
[*] AES stands for Advanced Encrytion Standard. The algorithm underlying AES is called Rijndael. AES is the successor of DES, the 20-year-old Data Encryption Standard.