Too many filesystems

By Abhijit Menon-Sen <>


While trying to explain something about filesystems the other day, I realised that there are too many different (but related) things that can be reasonably described by that term.

First, there's the general idea of a filesystem, discussed in every operating systems textbook, as an organisation of data into a hierarchy of named directories and files for persistent storage on disk. This is what people mean when they say Store data in the filesystem.

Second, there's the specific protocol that defines the UNIX filesystem, with characteristics such as files being just a series of bytes, having case-sensitive names and certain kinds of metadata, using '/' as a path separator, and supporting various operations (open, read, close, …).

Third, there are the many different filesystem implementations, such as UFS, ext3, XFS—all programs that implement UNIX filesystem semantics but have their own features, characteristics, extensions, and on-disk layout of data. This is the level at which one may decide to use, say, a journalling filesystem for a certain purpose.

Next, the layout of data on a disk, as distinct from whatever program is used to read or write that data, is also called a filesystem. This is the sense in which people might say The filesystem on /dev/sda1 is corrupted—the problem is (one hopes) not with the implementation, but with its instantiation on disk.

Finally, on a UNIX system, the filesystem may refer to the hierarchy of directories rooted at / and built up by mounting specific filesystems (in the "data on disk" sense) at various points on the tree. Thus, it is the union of the contents of its constituent filesystems.

These layers are usually taken for granted, but it is necessary to peel them away one by one to explain things properly.