The Linux Filesystem Standard, abbreviated FSSTND, is important to more than gurus. In this article, Garrett explains how it has worked behind the scenes to make life easier for all Linux users.
Many of us in the Linux community have come to take for granted the existence of great books on Linux like those being produced by the Linux Documentation Project. We are used to having various packages taken from different Linux FTP sites and distribution CDROMs integrate together smoothly. We have come to accept that we all know where critical files like mount can be found on any machine running Linux. We also take for granted CDROM based distributions that can be run directly from the CD, with only a small amount of physical hard disk or a RAM disk for some variable files like /etc/passwd, etc.
This has not always been the case. Many of us remember Linux from the days of the SLS, TAMU, and MCC Interim distributions of Linux. In those days, each distributor had his own favorite scheme for locating files in the directory hierarchy. (Actually, some can go back further, back to the days when the boot and root disks were the only means of getting Linux installed on your hard drive, but I have not been a member of the Linux community quite that long.) Unfortunately, this caused many problems when dealing with different distributions.
The Linux Filesystem Structure is a document created by a mailing list collaboration of contributors who wish to help end anarchy. Often the group, or the document itself, is referred to as the 'FSSTND'. This is short for "filesystem standard", and was the name of the original linux-activists channel. (The mailing list has since been moved to a different location.) Together, these people have put together a document which has helped to standardize the layout of filesystems on Linux systems everywhere. Since the original release of the standard, most distributors have adopted it in whole or in part, much to the benefit of their users.
Since the first draft of the standard, the FSSTND project has been coordinated by Daniel Quinlan, Daniel.Quinlan@linux.org, but the development of the standard has been nearly as open as Linux itself. The number of people who have contributed to the development of the document is quite large, since it was really developed by consensus. Some of the most significant contributors are listed in the FSSTND document itself.
There are a number of specific goals that the FSSTND group set out to accomplish at the outset. The first of these goals was to solve a number of problems that existed with the current Linux distributions at the time. Back then, it was not possible to have a sharable /usr partition, there was no clear distinction between /bin and /usr/bin, it was not possible to set up a diskless workstation, and there was just general confusion about what files went were. The second of these goals was to ensure the continuation of some reasonable compatibility with the de-facto standards already in use in Linux and other UNIX-like operating systems. Finally, the standard had to gain widespread approval by the developers, distributors, and users within the Linux community. Without such support, the standard would have been pointless, becoming yet another way of laying out the filesystem. Fortunately, the FSSTND has succeeded rather admirably in achieving its original goals.
There are also some goals that the Linux FSSTND project did NOT set out to achieve. The FSSTND does not try emulate the scheme of any specific commercial UNIX operating system (e.g. SunOS, AIX, BSD, etc.) Furthermore, for many of the files covered by the FSSTND, the standard does not dictate whether or not the files should be present, merely where the files should be -- if they are present. Finally, for most files, the FSSTND does not attempt to dictate the format of the contents of the files. (There are some specific exceptions when several different packages may need to know the file formats to work together properly. Take, for example, lock files that contain the process ID of the process holding the lock.) The overall goal was to establish the location where common files could be found, if they exist on a given machine.
The notion of having a standard that defines the location of certain files within a filesystem predates the FSSTND by quite a bit. AT&T's SVID defined the location of some files, as well as a lot of other things that most of us didn't really understand. POSIX provided a clearer standard for a very limited number of files. The genuine FSSTND discussion began in early August, 1993. Since then, despite some pessimism from some in the Linux community, the FSSTND has been enormously successful, releasing three public revisions of the document since September, 1993. The latest, v1.2, was released quite recently, on March 28, 1995.
Now if you're like me, you want to know "What does this do for me?" Well, the answer depends upon just who "me" is. The FSSTND has an impact upon Linux users, system administrators, distributors, documenters, and developers.
If you are Linux user, and you don't administrate your own Linux system (granted, this situation is somewhat rare) then the Linux FSSTND ensures that you will be able to find programs where you'd expect them to be if you've already had experience on another Linux machine. It also ensures that any documentation you may have makes sense. (From my own experience, nothing is more annoying than having inaccurate documentation!) Furthermore, if you've already had some experience with UNIX before, then the FSSTND shouldn't be too different from what you're used to using, with some exceptions.
Perhaps the most important thing is that the development of a standard brings Linux to a level of maturity that authors and commercial applications developers feel that they can support Linux. The recent explosion of Linux-related books is proof of this. Before the FSSTND, it would have been difficult to write books about Linux, since each and every system was different. The FSSTND is solving all that.
If you administer your own machine, you gain all the benefits of the FSSTND mentioned above. You also get the ability to feel more secure in the ability of others to provide support for you, should you have a problem. Furthermore, periodic upgrades of parts of your system are easier. Since there is an agreed-upon standard for the locations of files, package maintainers can provide instructions for upgrading that will not leave extra older binaries or support files lying around your system collecting disk space.
The FSSTND also means that there is more support from those providing source code packages for you to compile and install yourself. The provider knows, for example, where the executable for sed is to be found on a Linux machine, and can use that in his installation scripts or Makefiles. For instance, I've written a package does just this to generate man pages with correct file references in them, before it installs them. If you run a large network, the FSSTND may ease many of your NFS headaches, since it specifically addresses the problems which formerly made shared implementations of /usr impractical.
If you are a distributor, then you will be affected most by the Linux FSSTND. You may have to work a little extra to make sure that your distribution is FSSTND-compliant, but your users (and hence your business) will gain by it. If your system is compliant, then third party add-on packages (or possibly your own) will integrate smoothly with your system.
Your users will of course gain all the benefits listed above, and many of your support headaches will be eased. You will benefit from all the discussion and thought that has been put into the FSSTND, and avoid many of the pitfalls involved in designing a filesystem structure yourself. If you adhere to the FSSTND, you will also be able to take advantage of various features that the FSSTND was designed around. For example, FSSTND makes "live" CDROMs containing everything except some of the files in the / and /var directories possible.
If you write documentation for Linux, then the FSSTND makes it much easier to write documentation which makes sense to the Linux community. You no longer need to worry about the specific location of lock files on one distribution versus another, nor are you forced to write documentation that is only useful to the users of a specific distribution. The FSSTND is at least partly responsible for the recent explosion of Linux books being published.
If you are a developer, then the existence of a FSSTND greatly eases many of your headaches. You can know where important system binaries can be found, so you can use them from inside your programs or your shell scripts. Supporting users is also greatly eased, since you don't have to worry about things like the location of these binaries when resolving support issues. If you are the developer of a program that needs to integrate with the rest of the system, the FSSTND ensures that you can be certain what steps you need to take to meet this end.
For example, applications such as kermit which access the serial ports need to know they can achieve exclusive access to the tty device. The FSSTND specifies a common method of doing this so that all compliant applications can work together. That way you can concentrate on making more great software for Linux, instead of worrying about how to detect and deal with the differences in flavors of Linux.
As I've already indicated, the widespread acceptance of the FSSTND by the Linux community has been crucial to the success of both the standard and operating system. Fortunately, nearly every major distribution of Linux has been constructed to conform to the the Linux FSSTND. The odds are if you're running Linux you are running a FSSTND implementation. If your implementation isn't at least partially FSSTND compliant, then it is probably either very old or you built it yourself. The FSSTND itself contains a list of some of the distributions that aim to conform to the FSSTND. Be aware, however, that some of these distributions are known to cut some corners in their implementation of FSSTND.
The are, of course, still unresolved issues which the FSSTND group is still going to have to face. One of the upcoming ones is going the be the organization of architecture-independent scripts and data files (/usr/share). Up until now, Linux has only been widely available on i386 and compatible machines, so the need for standardization there was non-existant. The rapid progress being made by the ports to other architectures (MC680x0, Alpha, MIPS, PowerPC) suggests that this issue will soon need to be dealt with. Another issue that is under some discussion is the creation of an /opt directory as in SVR4 The goal for such a directory would be to provide a location for large commercial or third party packages to install themselves without worrying about the requirements made by FSSTND for the other directory hierarchies.
By now your appetite should have been whetted and you may want to read the actual FSSTND document yourself.
Information about how to participate in the continuing development of the FSSTND is contained in the FSSTND itself. The participants would appreciate it if you carefully read the complete document before you join in. That way you'll be better prepared to contribute in a valuable way to the development of the standard.
The FSSTND has provided the Linux community with an excellent reference document and has proven to be an important factor in the maturation of Linux. As Linux continues to evolve, so will the FSSTND. We are grateful towards Linus Torvalds, H. J. Lu, the Free Software Foundation, and many others who have helped make Linux available. The FSSTND team has helped to standardize Linux, making it useful to a wider audience.
I would like to thank Daniel Quinlan for his many valuable corrections and suggestions for improvement to this article.
You can obtain the FSSTND document via FTP from tsx-11.mit.edu in /pub/linux/docs/linux-standards/fsstnd/. There is also an excellent FAQ (Answers to Frequently Asked Questions) about the FSSTND, which is maintained by Ian McCloghrie, in the same directory.