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, in order 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 can’t 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 Second Extended filesystem, or ext2fs, which you probably use to store Linux files (also ext3 is slowly taking over); the VFAT filesystem, which allows files on Windows 95/98/ME partitions and floppies to be accessed under Linux; 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 6-1 lists the
filesystem types supported by the Linux kernel as of Version 2.4.10.
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 Section 7.4.2 in Chapter 7.
Table 6-1. Linux filesystem types
Filesystem |
Type |
Description |
---|---|---|
Second Extended filesystem |
ext2 |
Most common Linux filesystem |
Reiser filesystem |
reiserfs |
A journaling filesystem for Linux |
Third Extended filesystem |
ext3 |
Another journaling filesystem for Linux that is downward-compatible with ext2 |
Minix filesystem |
minix |
Original Minix filesystem; rarely used |
ROM filesystem |
romfs |
A tiny read-only filesystem, mainly used for ramdisks |
CRAM filesystem |
cramfs |
A compressed read-only filesystem, often used on PDAs |
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 files |
NT filesystem |
ntfs |
Accesses Windows NT files |
HPFS filesystem |
hpfs |
OS/2 filesystem |
|
proc |
Provides process information for ps |
Device filesystem |
devfs |
An alternate way of representing the files in the
|
ISO 9660 filesystem |
iso9660 |
Used by most CD-ROMs |
Joliet filesystem |
iso9660 |
An extension to the ISO 9660 filesystem that can handle Unicode filenames |
UDF filesystem |
udf |
The most modern CD-ROM filesystem |
System V filesystem |
sysv |
Accesses files from System V variants |
Coherent filesystem |
coherent |
Accesses files from Coherent |
UFS filesystem |
ufs |
Accesses files from UFS filesystems, like those on SunOS, BSD, or Tru64 Unix. |
BFS filesystem |
bfs |
Accesses files on SCO Unixware |
EFS filesystem |
efs |
Accesses files on older Irix versions |
ADFS filesystem |
adfs |
Accesses files from Acorn partitions |
AFFS filesystem |
affs |
Accesses files from standard AmigaOS filesystem partitions |
Apple Mac filesystem |
hfs |
Accesses files from Apple Macintosh |
QNX4 filesystem |
qnx4 |
Accesses files from QNX4 partitions |
JFFS filesystem |
jffs |
A filesystem for Flash-based devices |
Novell filesystem |
ncpfs |
Accesses files from a Novell server over the network |
SMB filesystem |
smbfs |
Accesses files from a Windows server over the network |
Coda filesystem |
coda |
An advanced network file system, similar to NFS |
RAM filesystem |
ramfs |
A filesystem for RAM disks |
Temporary filesystem |
tmpfs |
Another filesystem that is kept entirely in RAM |
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 Extended (ext2) filesystem, which was developed primarily for Linux and supports 256-character filenames, a 32-terabyte maximum filesystem size, and a slew of other goodies, or you will use the Reiser (reiserfs) or the Third Extended (ext3) filesystem. 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.) The Xia and Xenix filesystems available in older Linux kernels are no longer supported.
The main difference between the Second Extended filesystem and the Reiser filesystem is the fact that the latter is journalled. Journalling 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 journalled filesystem is the Third Extended filesystem, the successor to the Second Extended filesystem. This has the advantage of being downward-compatible with the Second Extended filesystem, but because it hasn’t been around for long, it is not used as much as the Second Extended and Reiser filesystems.
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 fits 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, while the NTFS filesystem lets you access Windows NT filesystems. The HPFS filesystem is used to access the OS/2 filesystem.
With the CVF-FAT
extension to the
DOS-FAT filesystem, it is possible to access
partitions that have been
compressed with
DoubleSpace/DriveSpace from Microsoft or Stacker from Stac. See the
file Documentation/filesystems/fat_cvf.txt
in
the Linux kernel sources for further details.
/proc
is a virtual filesystem; that is, no
actual disk space is associated with it. See Section 5.6.[17]
Like /proc
,
devfs
is a virtual filesystem. It is meant
as a replacement for the current /dev
directory
(see Section 6.3 later
in this chapter) and has the advantage that the special files there
do not have to be created manually by the system administrator, but
are rather created automatically and on demand by the kernel.
The ISO 9660 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.
Recently, Linux also received support for UDF, a filesystem that is meant for use with CD-RWs and DVDs.
Next, we have six 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 are UFS, EFS, BFS, System V, and Coherent. (The latter two are actually handled by the same kernel driver, with slightly different parameters for each.) 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 AmigaOS 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. Covering these is beyond the scope of this book; we have to point you to the Linux Network Administrator’s Guide by Olaf Kirch and Terry Dawson (O’Reilly) instead.
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 like you would on other platforms. For everybody, there are times, however, when you need to know how to mount and unmount media directly. We’ll 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.) The format of this command is:
mount -ttype
device
mount-point
where type
is the type name of the
filesystem as given in Table 6-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 Second Extended filesystem on the
partition /dev/hda2
and wish to mount it on the
directory /mnt
, use the command:
mount -t ext2 /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 8 plus 3 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 to 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 like CD-ROMs that are
nonwritable. You can successfully mount a CD-ROM
without the -r
option, but you’ll
get the 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”), as in:
umount /dev/fd0
to unmount 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 as 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 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, 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 ext2 (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
ext2
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 Section 6.1.5 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 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 / ext2 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 Section 6.2 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:
/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 Section 5.2.1 in Chapter 5). 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 Section 7.4.2 in Chapter 7 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 Section 8.6 in Chapter 8 for clues on what to do in this situation. If filesystem corruption is the problem, this can usually be repaired; see Section 6.1.5 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 like memory and network throughput.
If you want to use the automounter, you first need to turn this feature on when building your kernel. (See Section 7.4.2 in Chapter 7 for more details.) You will also need to enable the NFS option.
Next, you need to start the automount
daemon.
Because this feature is quite new, your distribution might not yet
have it. 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 sample
directory, and adapt 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
.
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 that each specify 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 so that 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, such as:
sources -fstype=nfs,soft sourcemaster:/sources
After editing the configuration files to reflect your system, you can start the automount daemon by issuing (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.[18] 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 like
/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.
In order 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, Second Extended filesystems using mkfs.ext2, 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.[19]
When you installed Linux, you may have created filesystems by hand
using a command such as mke2fs. (If not, the
installation software created the filesystems for you.) In fact,
mke2fs is equivalent to
mkfs.ext2. 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 -ttype
device
where type
is the type of filesystem to
create, given in Table 6-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, 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 exactly as
shown earlier, except that you would 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 Section 3.1.3.
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.[20] 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 3 on troubleshooting installation problems. They apply equally here.[21]
It is
sometimes
necessary to check your Linux
filesystems for consistency and 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 may 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 -ttype
device
where type
is the type of filesystem to
repair, as given in Table 6-1, and
device
is the device (drive partition or
floppy) on which the filesystem resides.
For example, to check an ext2 filesystem on
/dev/hda2
, you use:
rutabaga#fsck -t ext2 /dev/hda2
Parallelizing fsck version 1.06 (7-Oct-96) e2fsck 1.06, 7-Oct-96 for EXT2 FS 0.5b, 95/08/09 /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 Section 8.6 in Chapter 8 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 Section 5.2.2.3 in Chapter 5). 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 cause the
root filesystem to be
mounted as read-only, you can use either the ro
boot option, or 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/rc.sysinit
. 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 Extended filesystem, Minix filesystem, and Xia filesystem at least.
In Section 8.6 in Chapter 8, 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 underway 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.
[17] 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.
[18] We’ll cover the modprobe command in the next chapter.
[19] Under Linux the mkfs command historically created a Minix filesystem. On newer Linux systems, mkfs is a frontend for any filesystem type, and Minix filesystems are created using mkfs.minix.
[20] Debian users should use superformat instead.
[21] 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 the CD-Writing HOWTO for more details.