The Linux File System Standard

The Linux File System Standard, abbreviated FSSTND, is important to more than gurus. In this artile, 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 CD-ROMs 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 CD-ROM-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 File System 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 “file system standard”, and was the name of the original linux-activists mailing list 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 file systems 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 is nearly as open as Linux itself. The number of people who 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. The first goal 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 where. The second goal 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 be pointless, becoming just another way of laying out the file system. 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 to 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 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—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 machine.

The notion of having a standard that defines the location of certain files within a file system predates the FSSTND 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 on March 28, 1995.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState