It was big news when the 3.0 kernel was released at the end of July, but as luck would have it, another fundamental piece of your average distribution is about to bump its own version number up to 3.0 as well: the filesystem hierarchy standard (FHS). If you’re not sure exactly what that means or why you should care, don’t worry. It’s the distros that implement the FHS — when it goes well, all you know is that your system runs smoothly. But that doesn’t mean there’s nothing important hidden away in this new release.
The What Now?
The FHS defines the basic structure of a Unix-like operating system — what the directories are, what types of files and data belong in each, and so on. This is important for application developers (so that they know to create temporary files in /tmp/ rather than in the user’s home directory, for instance), but it is also important for system administrators. Not only does FHS specify where the directories go, but it specifies important properties like which directories must be mounted read-only (critical for security) and which must be available at boot time (so that vital directories are on local disks not NFS mounts that won’t be available early in the boot sequence).
This type of info is particularly important for systems like Linux that do not have a single corporate owner. IBM and Sun could dictate AIX and Solaris layout without consulting anyone. Red Hat, SUSE, and Debian, on the other hand, must reach a consensus about filesystem layout or deal with “fragmentation” complaints. Of course, the actual administrator of any machine can reconfigure the Linux system ad nauseum. For example, if you want to store all of your log files in /boot, your home directory in /etc, remove /bin/sh, and mount /usr/lib from an iSCSI drive, nobody will stop you (you’ll just have to migrate the configuration yourself). FHS merely specifies how to get a working system up and running out of the box.
FHS actually grew out of the old “BSD” hierarchy of prehistoric Unix days, although the modern *BSDs (FreeBSD, OpenBSD, NetBSD) have diverged since then. FHS has subsequently become a Linux-focused standard as more and more proprietary Unix vendors migrate to Linux from their historical product lines, and it is part of the Linux Standards Base (LSB). But the last update to FHS — version 2.3 — was released in 2004, which is ancient in computing terms.
Back in May of 2011, the Linux Foundation (who maintains LSB) decided to try and re-launch the FHS process, invite participation from all over the Unix-like landscape, and produce a long-overdue update. That effort is now nearing completion. FHS 3.0 will be an incremental update, reflecting new practices and making room for the ways in which computing has changed in the preceding seven years, rather than introducing radical new concepts.
What’s New in 3.0
The biggest change in FHS 3.0 is probably the addition of a new top-level directory, /run. The /run directory essentially moves /var/run (which used to hold run-time data that appears only after booting up, such as process ID (PID) files) up one level, and consolidates a few other dynamically-generated, non-persistent miscellany — including /var/lock lock-files, /dev/shm temporary storage, and udev state.
The goal is for /run to hold all system-state data that is not meaningful if persisted from one reboot to another. The /var directory where it resides in FHS 2.x is specified as being for “variable”-content files, but for the most part it is used by standard applications — for logs, email spools, caches, and so on. That means it is often stored on a separate partition, and may be mounted relatively late in the boot sequence. The /run directory contains core system information, and by being a separate top-level directory, it can be placed on the root partition to ensure its availability as soon as the init process needs it. The /run directory may also be used for per-user state data (such as session information), but there is an ongoing discussion about exactly how this option will be worded.
Games are also getting the once-over. Traditionally, games were treated differently than other user programs, with their own /usr/games and /var/games subdirectories. That was done for mostly historical reasons — the size of game data was large compared to other content, and because of its non-essential nature, not worth backing up on comparatively slow and expensive tapes. But the same could be argued for entertainment and other non-essential services, and backup storage has evolved considerably in recent years. The new plan is for games to use /usr/bin for binaries, /usr/share for game content, and /var/lib for “high score” data and other bits and pieces that potentially need to be accessible by multiple user accounts.
Speaking of consistency, SELinux has also lived in a non-standard location in the FHS 2.x era: in the top-level /selinux directory. This also changes in 3.0, moving to /sys/fs/selinux. References to the old X11R6 — found in /usr/X11R6 and other reserved places — have been deprecated at the request of X.org, who is close to incrementing the lost-standing protocol’s version number. Older references to xfree86 have also been excised, and ultimately “xorg” may take their name entirely. It may be hard to believe in 2011, but a decade ago there were commercial X servers that competed strongly with the reference XFree86 releases for admin’s business. None has much influence anymore.
There are plenty of other minor cleanups in the draft specification, including replacing references to the Bourne shell (sh) and Bash to accept any POSIX-compatible shell instead, clarifications on how independent software vendors can use /opt, and storage locations for man pages and ICC color profiles.
What’s Not New in 3.0 (or at Least, Not Yet)
That does not mean that everything is set in stone for 3.0 yet, however. Ongoing discussions include clarifying the use of the /srv directory, and important questions about how FHS relates to some other specifications, such as the XDG directory specs. You can read through the FHS discussion list archives to follow individual ideas, but a quicker overview of the process is available by looking at the FHS 3.0 “roll-up” bug and its dependencies. Note that not every issue listed in the dependencies will end up getting addressed in this release.
Despite the conservative change-set slated for inclusion in 3.0, the process of discussing proposed changes is interesting on its own, in part because it reveals what concerns are on administrators’ and distributors’ minds, and which might appear in future revisions.
For example, there is an ongoing debate over how to handle providing binaries for multiple processor architectures on a single system. At the moment, this generally means just supporting IA-32 (32-bit x86) binaries and IA-64 (64-bit amd64) binaries on one machine, but the conventional approach has its shortcomings. For one, it relegates 64-bit libraries to a specific /lib64 location while IA-32 relaxes in /lib — even if IA-64 is the vast majority of the libraries run. For another, it is an artificial limit, supporting just two architectures, and that always irritates standards committees. Debian has drafted its own approach to the problem as Debian Multiarch, which handles 32/64-bit architectures on a range of processor families, as well as mixed instruction sets using emulation.
There were also proposals to restrict the usage of /var, which is currently a hodgepodge of unrelated types of data, to create a top-level /export directory for network shares, and to merge the /usr hierarchy into / altogether. None looks particularly likely at the moment, but assuming that it is not seven years before the next FHS revision, the ideas may be revived.
That’s probably an important point; gathering interested parties in one place and discussing these issues help clarify the current state of affairs and gets the stakeholders thinking about new options. It was never a conscious decision to let the 2.3 release of FHS gather dust for seven years — it just slipped out of the collective consciousness. As a result, there were several Unix-like groups (such as the BSDs) who lost interest entirely and haven’t bothered to participate in the FHS 3.0 discussion. Hopefully the new release will put the standard back on a solid footing, and more useful debates will continue as it moves forward.
