UNIX Lecture Notes – Chapter 03

3.1 Introduction

This chapter looks at UNIX file systems from the programmer’s perspective. The primary objective is to be able to write programs that use the part of the UNIX API concerning the file system and its components. Of necessity, we will begin with an overview of what the le system is, and to a limited extent, how it is implemented. Although it is not necessary to understand how it is implemented to write programs that use it, a basic understanding of the typical implementation can help in understanding performance considerations and limitations.

3.2 File System Abstraction

A file system is an abstraction that supports the creation, deletion, and modification of files, and organization of files into directories. It also supports control of access to files and directories and manages the disk space accorded to it. We tend to use the phrase file system to refer to a hierarchical, tree-like structure whose internal nodes are directories and whose external nodes are non-directory-files (or perhaps empty directories), but a file system is actually the at structure sitting on a linear storage device such as a disk partition. The layout of Linux, for example, is shown in Figure 3.1. This at structure is completely hidden from the user, but not entirely from the programmer. The user sees this as a hierarchically organized collection of files and directories, which is more properly called the directory hierarchy or file hierarchy.

3.3 File System Mounting

Multiple storage devices are usually attached to a modern computer. Some operating systems treat the file systems on these devices as independent entities. In Microsoft’s DOS, and systems derived from it, for example, each separate disk partition has a drive letter, and the file hierarchy on each separate drive or partition is separate from all others attached to the computer. In effect, DOS has multiple trees whose roots are drive letters. For example, a typical Windows machine may have a directory E:\users on the “E:” drive and a directory “C:\Temp” on the “C:” drive but these directories are in two separate trees, not a single tree.

In UNIX there is a single file hierarchy. It is a tree if you think of the leaf nodes as filenames, but it is not a tree if you think of the leaf nodes as actual files, since a single file can have more than one name, existing as a directory entry in multiple directories, making the topology a directed acyclic graph1. We will take the liberty of referring to it as a tree, knowing that this is inaccurate.

In UNIX, every accessible file is in this single file hierarchy, no matter how many disks are attached. There is no such thing as the “C” drive” or “E” drive” in UNIX. This is because of the concept of mounting, which will be described in more detail later. In short, in UNIX, a file system may be mounted onto the single file hierarchy by attaching that file system’s root to some directory in the hierarchy. It is like grafting a branch onto a tree. By mounting a file system onto the file hierarchy, the file system becomes a subtree of the hierarchy, making it possible to navigate into the file system from the rest of the file hierarchy. The mount command without arguments displays a list showing all of the file systems currently mounted on the file hierarchy. As an example, the output of the mount command could be:

/dev/mapper/root.vg-root.lv on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext=”system_u:object_r:tmpfs_t:s0″)
/dev/sda1 on /boot type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

Each line is of the form,

file_system_name on place_where_it_is_mounted type file_system_type other_options

The sixth line states that there is a file system named /dev/sda1 of type ext3 that is mounted on the directory /boot. You may wonder about the meaning of the line

proc on /proc type proc (rw)

In a subsequent chapter we will explore the /proc file system, which is not a file system that manages disk space, but an interface to the kernel’s memory. Further interpretation of this output will be delayed until after a discussion of file systems and mounting in greater depth. At this point, the significance of mounting is that different file systems can be, and usually are, part of a single conceptual file hierarchy, making it possible to partition a disk into separate file systems that all become part of a single file hierarchy.