File Systems

Linux is built upon the foundation of file systems. They are the mechanisms by which the disk gets organized, providing all of the abstraction layers above sectors and cylinders. In this module, you’ll learn about the composition and management of these abstraction layers supported by the default Linux file system, ext2, and its more robust counterpart, ext3. This module covers the many aspects of managing disks. This includes creating partitions, establishing file systems, automating the process by which they are mounted at boot time, and dealing with them after a system crash. In addition to the basics, you’ll grow acquainted with some of the more complex features of Linux, such as mounting network file systems, managing quotas, and the Autofs service.

NOTE

Before beginning your study of this module, you should already be familiar with files, directories, permissions, and owners in the Linux environment. If you haven’t yet read Linux tutorial 6, it’s best to read that module before continuing.

Understanding File Systems

Let’s begin by going over the structure of file systems under Linux. It will help to clarify your understanding of the concept and let you see more easily how to take advantage of the architecture.

i-Nodes

The most fundamental building block of many UNIX file systems (including Linux’s ext2/ext3) is the i-node. An i-node is a control structure that points either to other i-nodes or to data blocks. The control information in the i-node includes the file’s owner, permissions, size, time of last access, creation time, group ID, etc. (For the truly curious, the entire kernel data structure is available in /usr/src/linux/include/linux/ext3_fs.h—assuming, of course, that you have the source tree installed in the /usr/src directory.) The one thing an i-node does not keep is the file’s name. As mentioned in Linux tutorial 6, directories themselves are special instances of files. This means each directory gets an i-node, and the i-node points to data blocks containing information (filenames and i-nodes) about the files in the directory. The i-nodes are used to provide indirection so that more data blocks can be pointed to—which is why each i-node does not contain the filename. (Only one i-node works as a representative for the entire file; thus it would be a waste of space if every i-node contained filename information.) Each indirect block can point in turn to other indirect blocks if necessary.

Superblocks

The very first piece of information read from a disk is its superblock. This small data structure reveals several key pieces of information, including the disk’s geometry, the amount of available space, and, most important, the location of the first i-node. Without a superblock, a file system is useless. Something as important as the superblock is not left to chance. Multiple copies of this data structure are scattered all over the disk to provide backup in case the first one is damaged. Under Linux’s ext2 file system, a superblock is placed after every group of blocks, which contains i-nodes and data. One group consists of 8,192 blocks; thus the first redundant superblock is at 8193, the second at 16385, and so on.

ext3

The ext2 file system is a well-tested subsystem of Linux and has had the time to be very well optimized. However, other file systems that were considered experimental when ext2 was created have matured and become available to Linux. There are four file systems one might consider to replace the aging ext2: ext3, ReiserFS, XFS, and JFS. All four of these file systems offer features that might be tempting in various circumstances, but the most important enhancement offered by all four is called journaling. Traditional file systems (such as ext2) must search through the directory structure, find the right place on disk to lay out the data, and then lay out the data. (Linux can also cache the whole process, including the directory updates, thereby making the process appear faster to the user.) The problem with this method of doing things is that in the event of an unexpected crash, the fsck program has to go in and follow up on all of the files that are on the disk in order to make sure that they don’t contain any dangling references (for example, i-nodes that point to other, invalid i-nodes or data blocks). As disks expand in size and shrink in price, the availability of these large capacity disks means more of us will have to deal with the aftermath of having to fsck a large disk. And as anyone who has had to do that before can tell you, it isn’t fun. The process can take a long time to complete, and that means downtime for your users. With journaling file systems, the new way of getting data out to disk, instead of finding the right place, the file system simply writes the data out in any order it can, as fast as it can. Each time, it logs the location of these data blocks. You can think of it as being like using the same spiral notebook for multiple classes without prepartitioning the notebook. It would be wiser to simply take notes for each class in chronological order instead of grouping all of one class together. A journaled file system is like such a notebook, with the beginning of the notebook containing an index telling you which pages contain all the notes for a single class. Once the data is written, the file system can go move things around to make them optimal for reading without risking the integrity of the file.

What this means to you as a system administrator is that the amount of time it takes for the disk to write out data is much less, while at the same time the safety of getting the data written out to disk quickly means that in the event of a system crash, you won’t need to run fsck exhaustively. Even when you do run fsck, it only has to check recently modified data, so instead of interminable times, you’ll find that the checks go very quickly. So which of the four journaling systems should you choose? That call is entirely up to you. But the only one I’ll talk about here is ext3, which is the default file system in Red Hat Linux 8.0.

Yes, I claimed earlier that ext2 was the default Linux file system, but when you install Red Hat you’ll find that the partitions default to ext3 unless you set them to something different. And that’s a good thing, for the reasons I just explained. Installing journaling file systems by default was one way Red Hat attempted to answer some of Linux’s critics, who noted that other operating systems already had that capability.

Managing File Systems

The process of managing file systems is trivial—that is, the management becomes trivial after you have memorized all aspects of your networked servers, disks, backups, and size requirements with the condition that they will never again have to change. In other words, managing file systems isn’t trivial at all. There aren’t many technical issues involved in file systems. Once the systems have been created, deployed, and added to the backup cycle, they do tend to take care of themselves for the most part. What makes them tricky to manage are the administrative issues—such as users who refuse to do housekeeping on their disks, and cumbersome management policies dictating who can share what disk and under what condition, depending of course on the account under which the disk was purchased, and . . . (It sounds frighteningly like a Dilbert cartoon strip, but there is a good deal of truth behind that statement.) Unfortunately, there’s no cookbook solution available for dealing with office politics, so this section will stick to the technical issues involved in managing file systems—that is, the process of mounting and unmounting partitions, dealing with the /etc/fstab file, and performing file-system recovery with the fsck tool.