When users think of a filesystem, they think of the
classic tree structure
composed of subdirectories and files. Everything begins
at the root
directory (/) and branches from there. Root is divided
which are further divided into additional subdirectories,
and so on.
Along the way are files within the subdirectories that
points on the branch, much like leaves on a literal
UNIX was designed with ease of use in mind. This tree
seemed the most efficient way to provide location and
access to files
and entities. It is no accident that users equate this
with the filesystem:
for most practical purposes, it is the filesystem. Administrators,
however, need to know that this tree is only the way
things look and
not the way they really are. They need to know that,
in reality, most
of the time there is a flatfile-style database that
to the data, and that the pointers and data comprise
the real filesystem.
This article examines filesystems from an administrative
explains what they are. In addition, it lists the tools
used to maintain
the filesystem and describes the most common types of
Simply, a filesystem is a collection of data. Every
machine has a minimum of one filesystem on a hard drive.
is the root system, which boots when the machine is
on. It contains the UNIX kernel (sometimes named /unix).
filesystem remains active for the entire time the machine
is up. (For
an overview of filesystems used by other operating systems,
sidebar "How Do Other Operating Systems Treat the
If there are additional filesystems on that machine,
they may be mounted
and unmounted at will. For example, once the machine
is up, the root
user can mount(1M) another hard drive partition that
files on it and can add new entries to a mailing list
adding the entries, the root user can unmount the partition
another with payroll information on it. Key points to
remember are:Data blocks -- which store the data.
For every entry in a directory listing, there is a corresponding
holding information about the file. Inodes are pointers
to the data
blocks holding the files. Inodes have the following
1. A unique inode number that increments by one with
every file or subdirectory created. Historically, inode
and one are set aside for special purposes. The root
begins with two.
2. A two-digit number for the type of entry:
01 -- a named pipe.
02 -- a character device file.
04 -- a directory.
06 -- a block device file.
10 -- an ordinary file.
12 -- a symbolic link.
14 -- a socket.
3. The permissions on the entity. Permissions are
four digits. The first digit tells whether a special
mode is set (1=sticky
bit, 2=SGID, 4=SUID). The remaining three digits tell
and execute permissions.
4. The physical size of the file.
5. The number of links to the entry.
6. The owner of the file, often in uid numeric form
-- the same information returned by the id command).
7. The group possessing the file -- again, often
in numeric form.
8. The timestamps for creation or change of the inode,
for last modification of the data, and for last access
of the data.
These are used in directory listings and by other commands,
when find looks for files meeting certain time criteria.
9. The physical data block addresses where the file
These nine items constitute the inode, although their
from one UNIX vendor to another. To see your system's
for the file /usr/include/sys/inode.h, or for a file
with "ino" in its name. (See the sidebar "NFS
for a discussion of network filesystems.)
Hard-linked files share the same inode number. Hard
links cannot cross
filesystems because each filesystem has its own inode
list. All inode
numbering starts at two and increments for the unique
The same number can appear on two different filesystems
to two different files.
Symbolic links, on the other hand, are nothing more
pointers from one place to another. Symlinks have unique
As pointers to other destinations they can cross filesystems.
link on the root filesystem can point to a particular
on the database filesystem even when the database filesystem
(For more information on inodes and the utilities used
them, see my article, "When Inodes Go Bad,"
in the July/August
1994 issue of Sys Admin.)
In the traditional UNIX world, there are two types of
Which one you used once depended on whether you had
UNIX flavor, or had opted for the BSD versions. AT&T's
is known as
S5, for System 5, reflecting the way versions are differentiated.
Berkeley's filesystem was called the Fast File System
(FFS) but is
now known as UFS. Today, both are usually available
on a new installation.
Knowing which to use can help you tailor your system
to meet your
site's specific needs. (See the sidebar "Other
for a brief discussion of other types of filesystems.)
Virtually all UNIX filesystems today use the concept
Write-Behind to increase their efficiency. With Read-Ahead,
you access the disk, more blocks are read into the buffers
the one you are requesting. Most of the time one request
by another. Often the next requested data is sequentially
the currently requested data. It makes sense to read
in more data
than that requested. When the next request is made,
that data is already
in memory, so there is no disk access time involved.
entails maintaining changes within the buffers and not
on the disk.
When activity slows down or the buffers fill, the buffers
the disk and prepare for the next operation. Given that
component inside any computer is the hard drive, you
can see how these
operations combine to increase processing efficiency
systems that don't use Read-Ahead and Write-Behind.
Figure 1 represents the physical structure of an S5
is also referred to by SCO as S51K. There is but one
boot block, one
superblock, and one inode list for the entire filesystem
else becomes data blocks. The boot block (logical block
primary and secondary bootstrapping programs. If you
create a nonbootable
filesystem, the space is still set aside for the boot
block, but that
space is not used or accessible. While size can differ
usually sectors 0 to 15 constitute the boot block, and
sector 16 is
the beginning of the superblock. The data blocks can
be either 512,
1024, or 2,048 bytes in size. Systems with many small
files can save
hard drive space by using blocks of 512 bytes, while
fewer files, larger in size, should have the block size
set to the
highest number possible.
Figure 2 shows a Berkeley Fast File System. UFS/FFS
uses the same
components as S5, but the components are not limited
only once on the disk. Instead, the superblock and inode
broken into smaller components and sprinkled throughout
the data blocks.
FFS was the default filesystem shipped with SVR4, and
the name has
now been changed to UFS for UNIX File System. Whereas
S5 allows for
structured blocks less than or equal to 2,048 bytes
in size, UFS supports
8,192-byte blocks. Because data is moved in blocks and
involves reading in additional blocks, the larger the
block, the more
efficient the operation. A side feature of UFS/FFS is
that it supports
255-byte names, as opposed to the 14-byte limit S5 imposes.
Its structure makes UFS much quicker and more efficient
than S5. Some estimates range as high as ten times quicker
The most crucial of the filesystem tools is mkfs(1M).
utility creates the filesystem. fsck(1M) performs cleanup
operations, should data or pointers get out of sync.
that are available depend on the UNIX vendor. These
include format or fmthard, both of which are used
to format the hard disk; dumpfs, to obtain information
the existing filesystem; and newfs, to rebuild a filesystem
without starting from scratch.
Selecting Which Filesystem to Use
Determining which filesystem is right for your installation
daunting. The answer is not always black and white,
nor may it be
universal for your entire system or network. You can
partitions on your system, each configured with a different
The first question to decide is whether you need many
or any multiple
partitions. There are a number of advantages to having
a small number
of large partitions:
Smaller partitions are easier to defragment. Fragmentation
occurs due to constant growth of some files and removal
When it occurs, the only solution is to make a complete
the filesystem, delete all the original files, and then
Restoring to an empty filesystem writes the files without
Once you have decided on the number of partitions and
each is to serve, the next step is to decide which filesystem
appropriate for that partition. Mixing and matching
is not only possible
Think about what the partition will be used for, then
is most appropriate for that application. With the root
partition, S5 works well, because the boot block will
be used, and
because the files within that partition do not change
or grow regularly.
With a partition containing database files, UFS makes
For such a partition, read and write access must be
as quick as possible.
Moreover, multiple superblocks provide a degree of protection
corruption. Should corruption occur, it will affect
only a percentage
of the filesystem's superblock rather than the whole.
Goodheart, Benny, and James Cox. The Magic Garden
Explained. Englewood Cliffs, N.J.: Prentice-Hall, 1994.
Sheldon, Tom. LAN Times Encyclopedia of Networking.
Berkeley, CA: Osborne McGraw-Hill, 1994.
About the Author
Emmett Dulaney is a product developer for New Riders
Publishing, and an
associate professor of Continuing Education at Indiana-Purdue
of Fort Wayne. He can be reached on CompuServe at 74507,3713.