Previous Section  < Day Day Up >  Next Section

9.1. Introduction

Understanding filesystem fundamentals is key to understanding how Linux works. Everything is a file—data files, partitions, pipes, sockets, and hardware devices. Directories are simply files that list other files.

The Filesystem Hierarchy Standard (FHS) was developed as a voluntary standard. Most Linuxes follow it. These are the required elements of the Linux root filesystem:


Root directory, even though it is always represented at the top


Essential system commands


Static boot loader files


Device files


Host-specific system configuration files


Shared libraries needed to run the local system


Temporary mount points


Add-on software packages (not used much in Linux)


Live kernel snapshot and configuration


System administration commands


Temporary files—a well-behaved system flushes them between startups


Shareable, read-only data and binaries


Variably sized files, such as mail spools and logs

These are considered optional because they can be located anywhere on a network, whereas the required directories must be present to run the machine:


User's personal files


Superuser's personal files

The FHS goes into great detail on each directory, for those who are interested. Here are some things for the Linux user to keep in mind:

  • /tmp and /var can go in their own individual partitions, as a security measure. If something goes awry and causes them to fill up uncontrollably, they will be isolated from the rest of the system.

  • /home can go in its own partition, or on its own dedicated server, for easier backups and to protect it from system upgrades. You can then completely wipe out and re-install a Linux system, or even install a different distribution, while leaving /home untouched.

  • Because all configuration files are in /etc and /home, backups are simplified. It is possible to get away with backing up only /etc and /home and to rely on your installation disks to take care of the rest. However, this means that program updates will not be preserved—be sure to consider this when plotting a disaster-recovery plan.

9.1.1 Linux File Types

Remember that "everything is a file." There are seven file types in Linux; everything that goes in the file tree must be one of the types in Table 9-1.

Table 9-1. File types

Type indicator

Type of file


Regular file






Character device




Named pipe


Block device

The type indicators show up at the very front of the file listings:

# ls -l /dev/initctl

prw-------  1 root   root     0 Jan 12 00:00 /dev/initctl

# ls -l /tmp/.ICE-unix/551

srwx------  1 carla  carla    0 Jan 12 09:09 /tmp/.ICE-unix/551

You can specify which file types to look at with the find command:

# find / -type p

# find / -type s

Ctrl-C interrupts find, if it goes on for too long.

9.1.2 File Attributes

Take a look at the attributes of a file, such as this shell script, sortusers:

$ ls -l sortusers

-rwxr-xr-x 1 meredydd  programmers   3783 Jan  7 13:29 sortusers

-rwxr-xr-x 1 meredydd programmers tells us a lot of things:

  • The - means that this is a regular file. This attribute is not changeable by the user. This is the bit that tells Linux what the file type is, so it does not need file extensions. File extensions are for humans and applications.

  • rwx are the file owner's permissions.

  • The first r-x is the group owner's permissions.

  • The second r-x applies to anyone with access to the file, or "the world."

  • 1 is the number of hard links to the file. All files have at least one, the link from the parent directory.

  • meredydd programmers names the file owner and the group owner of the file. "Owner" and "user" are the same; remember this when using chmod's symbolic notation u = user = owner.

Permissions and ownership are attributes that are configurable, with the chmod, chgrp, and chown commands; chmod changes the permissions, chown and chgrp change ownership.

All those rwx things look weird, but they are actually mnemonics: rwx = read, write, execute. These permissions are applied in order to user, group, and other.

So, in the sortusers example, meredydd can read, write, and execute the file. Group members and others may only read and execute. Even though only meredydd may edit the file itself, nothing is stopping group and other users from copying it.

Since this is a shell script, both read and execute permissions must be set, because the interpreter needs to read the file. Binary files are read by the kernel directly, without an interpreter, so they don't need read permissions.

9.1.3 File Type Definitions

Let's take a closer look at what the file types in Linux really are:

Regular files

Plain ole text and data files, or binary executables.


Lists of files.

Character and block devices

Files that could be considered as meeting points between the kernel, and device drivers—for example, /dev/hda (IDE hard drive), /dev/ttyS1 (serial modem), and so forth. These allow the kernel to correctly route requests for the various hardware devices on your system.

Local domain sockets

Communications between local processes. They are visible as files but cannot be read from or written to, except by the processes directly involved.

Named pipes

Also for local interprocess communications. It is highly unlikely that a Linux user will ever need to do anything with either sockets or pipes; they are strictly system functions. Programmers, however, need to know everything about them.


Links are of great interest to Linux users. There are two types: hard links and soft links. Links are pointers to files. A hard link is really just another name for a file, as it points to a specific inode. All the hard links that point to a file retain all of the file's attributes—permissions, ownership, and so on. rm will happily delete a hard link, but the file will remain on disk until all hard links are gone and all processes have released it. Hard links cannot cross filesystems, so you can't make hard links over a network share. Soft links point to a filename; they can point to any file, anywhere. You can even create "dead" soft links by deleting the files they point to, or changing the names of the files.

9.1.4 Filesystem Internals

Here are some more useful definitions relating to filesystems:

Logical block

The smallest unit of storage, measured in bytes, that can be allocated by the filesystem. A single file may consume several blocks.

Logical volume

A disk partition, a disk, or a volume that spans several disks or partitions—any unit of storage that is perceived as a single, discrete allocation of space.

Internal fragmentation

Empty spaces that occur when a file, or a portion of a file, does not a fill a block completely. For example, if the block is 4K, and the file is 1K, 3K are wasted space.

External fragmentation

Fragmentation occurs when the blocks that belong to a single file are not stored contiguously, but are scattered all over the disk.


A number of contiguous blocks that belong to a single file. The filesystem sees an extent as a single unit, which is more efficient for tracking large files.


First there were btrees (balanced trees), which were improved and became b+trees. These are nifty concepts borrowed from indexed databases, which make searching and traversing a given data structure much faster. Filesystems that use this concept are able to quickly scan the directory tree, first selecting the appropriate directory, then scanning the contents. The Ext2 filesystem does a sequential scan, which is slower.


Everything that describes or controls the internal data structures is lumped under metadata. This includes everything except the data itself: date and time stamps, owner, group, permissions, size, links, change time, access time, the location on disk, extended attributes, and so on.


Much of a file's metadata is contained in an inode, or index node. Every file has a unique inode number.

9.1.5 Journaling Filesystems

Our faithful old Ext2 filesystem is showing its age. It can't keep up with users who need terabytes to play with and who need fast recovery from service interruptions. For the majority of users, who still measure their storage needs in gigabytes or less, fast recovery and data integrity are the most important reasons to use a journaling filesystem.

Linux filesystems are asynchronous. They do not instantly write metadata to disk, but rather use a write cache in memory and then write to disk periodically, during slack CPU moments. This speeds up overall system performance, but if there is a power failure or system crash, there can be metadata loss. In this event, when the filesystem driver kicks in at restart and fsck (filesystem consistency check) runs, it finds inconsistencies. Because Ext2 stores multiple copies of metadata, it is usually able to return the system to health.

The downside to this is recovery time. fsck checks each and every bit of metadata. This can take from a few minutes to 30 minutes or more on a large filesystem. Journaling filesystems do not need to perform this minute, painstaking inspection, because they keep a journal of changes. They check only files that have changed, rather than the entire filesystem.

Linux users have a number of great choices for journaling filesystems, including Ext3, ReiserFS, XFS, and JFS. Ext3 is a journaling system added to Ext2. ReiserFS, XFS, and JFS are all capable of handling filesystems that measure in exabytes on 64-bit platforms. ia32 users are limited to mere terabytes, I'm afraid.

Which one should you use? There's no definitive "best" one; they're all great. Here's a rundown on the high points:


This one is easy and comfortable. That's what it's designed to be. It fits right on top of Ext2, so you don't need to rebuild the system from scratch. All the other filesystems discussed here must be selected at system installation, or when you format a partition. You can even have "buyer's remorse"—you can remove Ext3 just as easily. Because it's an extension of Ext2, it uses the same file utilities package, e2fsprogs. One major difference between Ext3 and the others is that it uses a fixed number of inodes, while the others allocate them dynamically. Another difference is that Ext3 can do data journaling, not just metadata journaling. This comes at a cost, though, of slower performance and more disk space consumed. Ext3 runs on any Linux-supported architecture.


ReiserFS is especially suited for systems with lots of small files, such as a mail server using the maildir format, or a news server. It's very efficient at file storage; it stuffs leftover file bits into btree leaf nodes, instead of wasting block space. This is called "tail packing." It scales up nicely, and it handles large files just fine. ReiserFS runs on any Linux-supported architecture.


This is IBM's entry in the Way Big Linux Filesystems contest, ported from AIX and OS/2 Warp. It supports multiple processors, access control lists (ACLs), and—get this—native resizing. That's right, simply remount a JFS filesystem with the new size you desire, and it's done. Note that you may only increase the volume size, not decrease it.


This is SGI's brainchild, ported from IRIX. XFS thinks big—it claims it can handle filesystems of up to nine exabytes. Its strength is handling very large files, such as giant database files. There is one excellent feature unique to XFS, called delayed allocation. It procrastinates. It puts off actually writing to disk, delaying the decision on which blocks to write to, so that it can use the largest possible number of contiguous blocks. When there are a lot of short-term temp files in use, XFS might never allocate blocks to these at all, in effect ignoring them until they go away. XFS has its own native support for quotas, ACLs, and backups and restores.

On a 32-bit system, there's only so much addressing space available, so the theoretical upper filesystem size limit is 16 terabytes (as of the 2.5 kernel). Calculating the maximum possible filesystem size depends on hardware, operating system, and block sizes, so I shall leave that as an exercise to those who really need to figure out those sort of things.

Another way to while away the hours is to compare performance benchmarks, or run your own. About all they agree on is that Ext3 really isn't suited for high-performance, high-demand applications. It's fine for workstations and light-to-medium-duty servers, but the others are better choices for high-demand servers.

9.1.6 When Not to Use a Journaling Filesystem

Stick with plain ole Ext2 when you have a /boot partition and are running LILO. LILO cannot read any filesytem but Ext2 or Ext3. The /boot partition is so small, and so easily backed up and restored, that there's no advantage to be gained from journaling in any case. You can put a journaling filesystem on your other partitions; in fact, you can mix and match all you like, as long as your kernel supports them.

On small partitions or small disks, such as 100-MB Zip disks, the journal itself consumes a significant amount of disk space. The ReiserFS journal can take up to 32 MB. Ext3, JFS, and XFS use about 4 MB, but if data journaling is enabled in Ext3, it will eat up a lot more space.

9.1.7 See Also

    Previous Section  < Day Day Up >  Next Section