lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
oldlinux-files/docs/linux-standards/private/fsstnd/pre-release/draft-94.01.15
gohigh 9912ec445d add directory docs
2024-02-19 00:23:35 -05:00

1832 lines
61 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Linux Filesystem Structure Advance Draft
Daniel Quinlan, quinlan@bucknell.edu
Filesystem Standard Group
ABSTRACT
This document is an extensive undertaking to correct
outstanding problems with the Linux filesystem structures in
use by developers, programmers, administrators, and users.
Our purpose and goal is to describe a filesystem structure
of exceptional quality that developers and others will
voluntarily adopt to solve well-acknowledged problems.
The FSSTND group hopes that this draft will be
eventually adopted as a better standard than the de-facto
standard produced by the current disarray of ideas.
1. Foreword
1.1. Status of this Draft
This draft is being distributed to members of the Linux community in
order to solicit their reactions to the series of ideas, concepts, and
proposals included within it. While the entire content of this draft
may not conform to what every individual desires, it should prove to be
a good start to solving many problems.
This draft is a working document of the Filesystem Standard (FSSTND)
mailing list, the author, and many others who have worked together to
make this draft possible.
1.2. Legalese
Copyright (C) 1994 Daniel Quinlan (quinlan@bucknell.edu)
Permission is granted to copy and distribute verbatim copies of this
document provided the copyright and this permission notice are preserved
on all copies.
- 1 -
Linux Filesystem Structure January 15, 1994
Permission is granted to copy and distribute modified versions of this
document under the conditions for verbatim copying, provided that no
text from this document is removed from the derived work, that
modifications are clearly marked, and that the entire resulting derived
work is distributed under terms of a permission notice identical to this
one.
UNIX is a Registered Trademark of X/Open Co. Ltd.
All other copyrights are owned by their owners, unless specifically
noted otherwise. Use of a term in this document should not be regarded
as affecting the validity of any trademark or service mark.
- 2 -
Linux Filesystem Structure January 15, 1994
2. Introduction
We originally felt that it was desirable to first call attention to some
of the fundamental problems with the current filesystem situation:
o There was no single well-accepted Linux directory structure.
Instead, there are many different ones, each being incompatible
with each other. This is a problem that justifies our effort and
should overshadow any differences in opinion, the same differences
in opinion that make Linux filesystems an utter mess.
o In the most widely used filesystem hierarchies, the directories
were not well structured and differ gratuitously from more modern
standards (such as POSIX, System V, BSD, and others).
o The filesystem was disturbing to experienced UNIX** users and
administrators who have experience on more mainstream UNIX
systems.
o The current layout was confusing for Linux newcomers, especially
those coming from a non-UNIX background.
o Any incompatibilities between primary installation packages and
other software packages are typically solved by methods of a less
than appealing nature.
o Overall, symbolic links are used too often within the filesystem
to fix problems. (However, there are times when symbolic links
need to be used to ensure backward compatibility or to allow
specific systems to have an individual filesystem structure.)
The FSSTND group seeks to correct these problems by proposing a good
filesystem structure that the Linux community may voluntarily follow.
While developing this draft, approval and input was received from a
number of Linux developers, noted Linux programmers, many system
administrators, and both experienced and novice users. For this reason,
we think that following our recommendations is a good thing. If you
feel that there is a problem with this effort or the substance of the
draft, feel free to first contact the draft coordinator, Daniel Quinlan
<quinlan@bucknell.edu>, with your comments.
2.1. Specific Problems
Naturally, while defining a Linux filesystem structure, there were some
specific problems that we sought to correct. Here are some of the major
and well-accepted ones:
_________________________
** UNIX is a Registered Trademark of X/Open Co. Ltd.
- 3 -
Linux Filesystem Structure January 15, 1994
o The primary binary directories, /bin and /usr/bin, do not have
well defined divisions between them. As a result, the binaries
that are in found in each directory greatly differ between various
Linux distributions.
o Including both binaries and configuration files in /etc makes it
more confusing and harder to maintain for inexperienced users or
system administrators with especially large systems.
o The divisions between /usr/etc and /etc as a location for
configuration is muddled at best. This is because the boundary
between what is a site-wide configuration file and what is a
machine-local configuration file is difficult to establish.
o The current implementation of /usr cannot be mounted read-only
because it contains variable files and directories that need to be
written to.
o In a networked environment it is desirable to serve software to
workstations via a NFS mounted filesystem. Such filesystems need
to be mounted read-only so that accidents or malice on one
workstation cannot damage the files on the server. This requires
identification and separation of files that a machine must write
to and separation of files that are specific to a single machine.
o Linux is not well prepared for a network installation including
the possibility of a read-only /usr partition and diskless (or
small local disk) workstations.
While these are some of the major problems we addressed, there were
numerous additional problems that needed to be solved. This draft
attempts to address many of those other problems, but there may be
something we missed. If you wish to bring something to our attention,
please note there are some things we have discussed at length, but did
not include in this draft (for good reasons).
2.2. Objectives
In trying to solve the above problems, we saw several objectives that
needed to be accomplished in addition to the more technical matters.
These goals comprise the correction of outstanding problems as well as
the validation of our discussion and work.
o Solve the above problems while also limiting the possible
transition difficulties resulting from moving away from the former
de-facto standards.
o Gain approval of distributors, developers, and other important
people in the Linux movement, as well as their suggestions.
- 4 -
Linux Filesystem Structure January 15, 1994
o Provide a standard that all of the Linux community would choose to
follow because it will solve the above problems as well as provide
the most sensible structure for Linux's filesystem.
o While conforming to this or any other standard in Linux is
obviously completely voluntary, we wanted to impress upon
developers that this organization is a very sensible way to lay
out a Linux filesystem. If you, as a developer, wish to suggest
any improvements, we are quite willing to listen.
2.3. History and Progress
The original post that motivated this effort to restructure the Linux
filesystem was written by Olaf Kirsh <okir@monad.swb.de> on August 2,
1993 to the NORMAL channel of the Linux activists mailing list.
Soon thereafter, it was decided that the best way to accomplish such a
restructuring of the Linux filesystem would be to create a mailing list
for the purpose of trying to develop a consensus standard.
After a comprehensive discussion, with surprisingly few flames, a
preliminary draft was written. Then, with the help of several dedicated
people, the draft was finished and that resulting draft submitted to the
FSSTND channel for more discussion. The first draft was submitted to
the channel on September 18, 1993 by Daniel Quinlan.
As the discussion continued and this draft of FSSTND recommendations was
developed further, contacts were established with accessible Linux
distributors who then offered their input and support to our effort.
Many Linux developers already agree that what we are doing is a good
thing. These are some of the developers who are trying to follow the
recommendations of the FSSTND draft [alphabetical order]:
o Debian Linux
Ian A. Murdock <imurdock@shell.portal.com>
o Linux/PRO
Fred N. van Kempen <waltje@metallica.uwalt.nl.mugnet.org>
o Slackware Linux
Patrick J. Volkerding <volkerdi@mhd1.moorhead.msus.edu>
o TAMU Linux
Dave Safford <drs0587@net.tamu.edu>
o util-linux packages
Rik Faith <faith@cs.unc.edu>
- 5 -
Linux Filesystem Structure January 15, 1994
The draft, although much more stable and comprehensive than it once was,
will probably never be truly finished -- the needs of the Linux
community will continually change in relation to emerging technology.
It is also possible that better solutions to filesystem problems could
be discovered. We are not above making mistakes nor are we unwilling to
admit them. Because of these reasons, the FSSTND group plans to release
supplementary drafts in addition to periodic updates to the main draft.
-- Daniel Quinlan [93/12/21]
- 6 -
Linux Filesystem Structure January 15, 1994
3. The Filesystem
The UNIX filesystem is characterized by:
o a hierarchical structure
o consistent treatment of file data
o protection of file data
Our recommendations on the Linux filesystem follow the same basic
principles as the UNIX filesystem. However, we did not try to conform
in every possible respect to the UNIX (SVR4) filesystem structure.
This is after careful consideration of other factors, including:
o common (good) practices in the Linux community
o the existence of other filesystem structures (such as BSD)
o applicable standards (such as POSIX)
The directory hierarchy is separated into unsharable data, "/" (root),
and sharable data, "/usr". These two filesystems are divided according
to the following two data types: static data and variable data. Static
data includes binaries, libraries, documentation, and anything that does
not change without system administrator intervention. Variable data is
anything that does change without the system administrator's
intervention.
(In this document, the term "filesystem" is used to refer to either a
single formatted partition for data, or to refer to the entire directory
hierarchy.)
We have defined 2 orthogonal categories of file data: sharable-
unsharable and variable-static. We have defined /usr as sharable data
and / as unsharable data. Each hierarchy, / and /usr, divides data into
static and variable types. Throughout this document, and in any well
planned filesystem, the acceptance of these facts will help guide the
structure and lend it additional consistency.
The distinction between sharable and unsharable data is needed for
several reasons:
o In a networked environment, certain filesystems contain
information specific to a single machine. Therefore these
filesystems cannot be shared (with NFS).
o The current implementation of /usr cannot be mounted read-only
because it contains variable files and directories that need to be
written to. This is a factor that must be addressed when /usr is
- 7 -
Linux Filesystem Structure January 15, 1994
shared on a network or mounted read-only because of other
considerations (safety).
The "sharable" factor can be extended in two directions:
o A /usr mounted (read-only) through the network (using NFS).
o A /usr mounted from read-only media. (You can think of that CD-
ROM drive as a networked, using postal mail, filesystem that you
are sharing with other Linux systems.)
The "static" vs. "variable" factor dramatically affects the filesystem
in 2 major ways:
o Since / contains both variable and static data, it needs to be
mounted read-write
o Since /usr contains both variable and static data, and since we
want to mount it read-only (see above), it is necessary to provide
a method to have /usr mounted read-only. This is done through the
creation of a /var hierarchy which is mounted read-write (or is a
part of another read-write partition, such as /), taking over much
of the /usr partition's traditional functionality.
- 8 -
Linux Filesystem Structure January 15, 1994
4. The root directory
This is the root directory structure. In general, enough data should be
contained in the root partition to boot, restore, recover, and/or repair
the system:
(1) To boot a system, enough must be present to mount /usr. This
includes utilities, configuration, boot loader information, and
other essential start-up data.
(2) To recover and/or repair a system, those utilities needed by an
experienced user to diagnose and reconstruct a damaged system
should be present on root.
(3) To restore a system, those utilities needed to restore a system
from backups (on floppy, tape, etc.) should be present on root.
The primary concern used to balance these desires (placing many things
in root) is the goal of keeping root as small as reasonably possible.
It is desirable to keep root small in terms of number of directories,
files, and disk space for several reasons:
(1) The root is often mounted from very small media. For example,
most people using Linux install and do recovery by mounting root
off of a RAM disk which is copied from a single 1.44M or 1.2M
floppy disk.
(2) Root has many system-specific configuration files in it, a kernel
that is specific to the system, a different hostname, etc. This
means that root isn't always sharable between networked systems.
Keeping root small on networked systems minimizes the amount of
space lost on servers to unsharable files. It also allows
workstations with smaller local hard drives.
However, with diskless clients, this does not have to be entirely
the case, unless each client has a different root image.
(3) While you may have a large root partition, and may be able to
fill it to your heart's content, there will be people with
smaller partitions. If you have more files installed, you may
find incompatibilities with other systems using limited root
partitions. If you are a developer then you may be sharing this
problem with a large number of users.
(4) Disk errors on the root partition are a greater problem than
errors on any other partition. A small root partition is less
prone to corruption as the result of a system crash.
Since root is small and host-specific (due to the division between / and
/usr), this scheme necessitates a writeable root. However, this does
not necessitate a fully locally stored root. The root partition doesn't
- 9 -
Linux Filesystem Structure January 15, 1994
have to be locally stored just to be system specific (i.e., root mounted
from a NFS root server.)
Software should never create or require special files or subdirectories
in the root directory. This structure provides more than enough
flexibility for any package. Any package which does occupy a directory
under root suffers from sheer arrogance.
/ : the root directory
|
|- bin : essential command binaries
|- boot : static files of the boot loader
|- dev : device files
|- etc : machine-local system configuration
|- home : user home directories
|- lib : shared libraries (libc.so.*, libm.so.*, and ld.so)
|- mnt : mount point of temporary partitions
|- proc : process information pseudo-filesystem
|- root : home directory for root
|- sbin : essential system binaries
|- tmp : temporary files
|- usr : second major permanent mount point
|- var : files that tend to grow or vary in size
+- {kernel image}
Following this section, each directory is explained in full. /usr and
/var are discussed in separate sections of this draft.
The root directory normally contains the current kernel image. The
kernel image name is locally configurable, but the name we suggest (that
has been used in recent Linux kernel sources) is `vmlinux' which may or
may not be a (symbolic-)link to the actual file, possibly depending on
the system distribution used. More information on kernel placement is
located in the /boot section of the draft.
4.1. /bin : essential command binaries (for use by all users)
There should be no subdirectories within /bin.
The commands (static data) that are needed in single user mode by the
super-user (root) are stored in /bin. However, the commands in /bin are
for use by both root and other users. On the same note, the /bin
directory should not contain anything that is to be used only by root
for system administration.
All root-only binaries such as standard daemons, `init', `getty',
`mkfs', et al. (previously found in /etc), shall now be placed in /sbin
or /usr/sbin depending on the necessity of the command. For discussion
and our definition of essential (necessity and related concepts) please
read the issues and rationale section towards the end of this draft.
- 10 -
Linux Filesystem Structure January 15, 1994
Command binaries that are not essential enough to place into /bin should
be placed into /usr/bin, instead. Items which are only used by non-root
users are not essential (interactive shells, pagers, `passwd', et al.)
and should be placed elsewhere.
REQUIRED files for /bin:
o general commands:
The following commands have been added because they are essential. A
few have been added because of their traditional placement in /bin.
{ arch, cat, chgrp, chmod, chown, cp, date, dd, df, echo, ed, false,
free, kill, ln, loadkeys, login, ls, mkdir, mknod, mv, ps, pwd, rm,
rmdir, setserial, sh, stty, su, sync, true, uname }
If /bin/sh is BASH, then /bin/sh should be a symbolic or hard link to
/bin/bash since bash behaves differently when called as `sh' or
`bash'. The same goes for `pdksh', which is often the /bin/sh on
install disks and such (link from /bin/sh to /bin/ksh). I personally
prefer the advantage of using a symbolic link in these cases, because
it allows users to easily see that /bin/sh is not a true Bourne
shell.
Both `[' and `test' are built into BASH, pdksh, zsh, recent Korn
shells, ... essentially every Bourne shell replacement there is for
Linux. They should be placed into /usr/bin. (That is, they must be
included with any Linux system, attempting to comply with the POSIX.2
standard.)
/bin/arch should produce the same output as "uname -m", specifically
"i386" or "i486".
o restoration commands:
These commands have been added to make restoration of a system
possible (provided that / is intact).
{ tar, gzip, gunzip (link to gzip), zcat (link to gzip) }
If system backups are made with a package other than `gzip' and
`tar', then that administrator should include the minimal necessary
restoration components in the root partition. For instance, many
systems should include `cpio' as it is the next most commonly used
backup utility after tar. Conversely, if no restoration from the
root partition is ever expected, then these binaries may be omitted
(e.g., a ROM chip root, mounting /usr through NFS). If restoration
of a system is planned through FTP, then ftp or tftp (along with
everything necessary to get an ftp connection) should be available on
the root partition.
- 11 -
Linux Filesystem Structure January 15, 1994
o networking commands:
These are deemed the only necessary networking binaries that both
root and users will want or need to execute other than the ones in
/usr/bin or /usr/local/bin.
{ domainname (link to hostname), hostname, netstat, ping }
4.2. /boot : static files of the boot loader
This directory contains everything for boot except configuration files
and the map installer. This includes saved master boot sectors, sector
map files, and anything else that is not directly edited by hand. The
boot loader program should be placed into /sbin and configuration files
for boot loaders into /etc.
For LILO:
Old location New location
------------------------ -----------------
/etc/lilo/config.defines /etc/lilo.defines
/etc/lilo/config /etc/lilo.conf
/etc/lilo/disktab /etc/disktab
/etc/lilo/lilo /sbin/lilo
/etc/lilo/boot.NNNN /boot/boot.NNNN
/etc/lilo/part.NNNN /boot/part.NNNN
/etc/lilo/map /boot/map
/etc/lilo/*.b /boot/*.b
*.b are the first and second stage boot loader, plus all those chain
loaders. `QuickInst' (if it is included) should be placed into
/usr/sbin. (The `activate' command is left out of this scheme because
its future is uncertain at this time.)
Extra kernel images may be stored in /boot. The main kernel can either
be placed in / or in /boot according to preference of the administrator.
If placed in /, the kernel may also possibly be a symlink to a kernel
image in /boot. Note that the standard location for the kernel is still
in /.
4.3. /dev : Device files
/dev usually also contains a file, MAKEDEV, a shell script designed to
create devices as needed. It also often contains a MAKEDEV.local for
any local-only devices.
Symbolic links in /dev should not be distributed with Linux systems, as
the local setup will often differ from that on the distributor's
development machine. Also, if a distribution install script configures
- 12 -
Linux Filesystem Structure January 15, 1994
the symlinks at install time, these symlinks will often not get updated
if local changes are made in hardware. When used responsibly at a local
level, however, they can be put to good use.
This standard incorporates the the Linux Device List which is maintained
by Rick Miller <rick@ee.uwm.edu>, the Linux Device Registrar. This is
the current standard that we strongly recommend using. It is available
by anonymous ftp at sunsite.unc.edu as /pub/Linux/docs/hardware/DEVICES.
4.4. /etc : Machine-local system configuration
No binaries should go directly into /etc. Binaries which would have in
the past been found in /etc should now be placed in /sbin. This
includes such files as init, getty, and update. Binaries such as
hostname which are used by users as well as root should not be placed in
/sbin, but in /bin.
REQUIRED files for /etc:
o general files:
These files are needed on most Linux systems.
{ adjtime, csh.login, fdprm, fstab, gettydefs, group, inittab, issue,
ld.so.conf, magic, motd, mtab, mtools, passwd, printcap, profile,
securetty, shells, termcap, ttytype, utmp }
The `securetty' file is not truly required because the "getty_ps"
package uses a list in it's `login.defs' by default.
o networking files:
These are only needed if networking is installed.
{ ftpusers, hosts, host.conf, hosts.equiv, networks, protocols,
resolv.conf, services }
There are two models for setup of the "rc" command scripts which are
invoked by init(8) at boot time, the /etc/rc.* (BSD model) and the
/etc/rc.d/* (System V model). Either model is acceptable at this time.
This is a local issue and the implementation that is used should be
determined by the system administrator or the developer.
The `wtmp' log file belongs in /var/adm because it can grow in size
without bound.
Systems which choose to use the shadow password suite will have
additional files in /etc (/etc/shadow and whatever else) and /usr/sbin
(useradd, usermod, et cetera).
- 13 -
Linux Filesystem Structure January 15, 1994
If you use getty_ps, there might also be a couple of other files:
login.defs, default/getty.ttyS*, etc. [I am not especially thrilled
about the "default" subdirectory of /etc, but that is another matter
-djq]
4.5. /home : User home directories
/home is a fairly standard concept, but it is clearly a site-specific
filesystem. The setup will differ from machine to machine. This is
only a suggested placement for user home directories, but we recommend
that all Linux distributions utilize this as the default home directory.
On small systems, each user's directory is typically one of the many
subdirectories of /home such as /home/smith, /home/linus,
/home/operator, etc.
On large systems (especially when the /home directories are mounted
across a number of machines using NFS) it is a good idea to subdivide
user home directories. Subdivision can be accomplished by using
subdirectories such as /home/staff, /home/guests, /home/students, etc.
Different people prefer to place user accounts in a variety of places
and because of this reason, no programming should rely on this location.
If you want to find out a user's home directory, you should use the
field in /etc/passwd or another reliable method (if a program is being
run by a user, the $HOME variable is a fairly reliable method).
4.6. /lib : Shared libraries (needed to run dynamically linked binaries)
Only the shared library images necessary to boot the system should be
placed in /lib. The shared library images are "/lib/libc.so.*",
"/lib/libm.so.*", and "/lib/ld.so" (and not the actual ".a" files).
XFree86 and other libraries do not belong in /lib. Essentially, only
the dynamic shared libraries needed to run programs in /bin and /sbin
should be here.
A single symbolic link for the C preprocessor currently exists in /lib
pointing /lib/cpp to /usr/bin/cpp which should be either be the actual
`cpp' binary or a link to /usr/lib/gcc-lib/i?86-*-linux/2.5.?/cpp. No
commands should be added to /lib in addition to `cpp'. /lib/cpp is
where XFree86 and some other packages expect to find the C preprocessor.
4.7. /mnt : Mount point for temporarily mounted filesystems
This is the location where the system administrator may temporarily
mount filesystems as needed. The setup of this directory is a local
issue and should not affect the manner in which any program is run.
- 14 -
Linux Filesystem Structure January 15, 1994
This directory should probably not be used by installation programs due
to the site-specific nature of it. A temporary directory not in use by
the system should be used instead.
4.8. /proc : Proc based process system
The procps filesystem is becoming the standard Linux method for handling
process information rather than /dev/kmem and other nasty methods. This
is only recommended, but may in time become the standard for the storage
and retrieval of process information as well as other kernel and memory
information.
4.9. /root: home directory for root
/ is traditionally the home directory of the root account, however on
most Linux systems this is found in /root. One thing that is certain is
that the root account's home directory must be stored on the root
partition.
It is preferred practice not to use the root account for mundane things
such as mail and news, but solely for systems administration. For this
reason, subdirectories such as "Mail" and "News" should not appear in
the root account's home directory. Mail is usually forwarded to a more
appropriate account.
4.10. /sbin : System binaries (binaries once kept in /etc)
Utilities used for system administration (and other root-only commands)
are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin typically
contains files essential for the booting phase of starting the system
up. Anything executed after /usr is known to be mounted (when there are
no problems) should be placed into /usr/sbin. Local-only system
administration stuff should now be placed into /usr/local/sbin.
The concept of what goes into "sbin" directories is simple. If a user
will need to run it, then it should go somewhere else. If it will only
be run by root (i.e., system administration commands, networking
daemons, system startup), then it should go in /sbin (or in /usr/sbin if
the item is not essential to system operation). Files such as `chfn'
and `ac' which users only occasionally use should still be placed in
/usr/bin. `ping', although it is absolutely necessary for root (network
recovery and diagnosis) is often used by users and should live in /bin
for that reason.
If there is any chance that a user should need to run it, do not put it
here! Users should never have to place /sbin (or any of the "sbin"
directories) in their path. It is true that they should probably not
even be able to execute anything dangerous in /sbin if the job has been
- 15 -
Linux Filesystem Structure January 15, 1994
done correctly. It is reasonable to let them see what files are in
/sbin. Therefore, don't make the directory totally unreadable unless
you must.
/sbin was not created to protect users or to prevent them from seeing
the OS, but to provide a good division between binaries that everyone
uses and the commands that are to be used only by administrators.
REQUIRED files for /sbin:
o general commands:
{ clock, getty, init, update, mkswap, swapon, swapoff }
o shutdown commands:
{ halt, reboot, shutdown }
o filesystem commands:
{ fdisk, fsck, fsck.*, tunefs (Ext2 only), mkfs, mkfs.*, mount,
umount }
"*" = (ext, ext2, minix, msdos, xiafs)
o LILO commands:
{ lilo }
o networking commands:
{ arp, ifconfig, ifsetup, route }
OPTIONAL files for /sbin:
o static binaries:
Static ln and static sync are useful when things go wrong. The
primary use of sln (to repair hosed symlinks in /lib after a poorly
orchestrated upgrade) is no longer a major factor now that the
`ldconfig' program exists and can act as a guiding hand in upgrading
the dynamic libraries. Static sync is useful in some emergency
situations. Note that these are not just statically compiled
versions of `ln' and `sync'.
The `ldconfig' binary is optional for /sbin as well. Basically, if
you use it properly when upgrading the shared libraries in /lib, you
won't need it in root.
{ ldconfig, sln, ssync }
- 16 -
Linux Filesystem Structure January 15, 1994
4.11. /tmp : temporary files
/tmp is used for temporary files, preferably on a fast device (a memory
based filesystem, for instance).
The "persistence" of the data that is stored in /tmp is different than
that which is stored in /usr/tmp. /tmp is usually cleaned out at boot
time (or at relatively frequent intervals). Because of this, data
stored in /tmp should not be expected to remain for any long period of
time on the system... it is frequently deleted.
Programs should use /tmp or /usr/tmp (which is usually symlinked to
/var/tmp) according to the expected persistence of the data, but should
not rely on any particular persistence for any tmp directories
The precise arrangement of /tmp and /usr/tmp is a local issue. If there
are distinct /usr/tmp and /tmp directories, then the persistence of
/usr/tmp files should be at least as long as for /tmp, but beyond that,
a site administrator or distributor can arrange these any way they want,
over RAMdisk, symlinks or whatever.
- 17 -
Linux Filesystem Structure January 15, 1994
5. The /usr directory
/usr is the second major division of the filesystem. /usr is sharable
data. That means that /usr should be sharable between various machines
running Linux. Because it is sharable between machines, any information
that is machine-local must be stored elsewhere, hence /var enters the
picture.
/usr : Second major mount point (permanent)
|
|- X386 : X Window system on x86 platforms
|- bin : Most user commands
|- dict : Word lists
|- doc : Miscellaneous documentation
|- etc : Site-wide system configuration
|- g++-include : GNU C++ include files
|- games : Games and educational binaries
|- include : Header files included by C programs
|- info : GNU Info system's primary directory
|- lib : Libraries
|- local : Local directory (empty after main installation)
|- man : Online manuals
|- sbin : Non-vital system administration binaries
|- share : Architecture-independent data
|- src : Source code
+- tmp : Temporary files, used to keep /tmp small.
The following list of directory symbolic links need to be added. This
only needs to be done until compatibility with the /var scheme can be
assumed to exist.
/usr/adm -> /var/adm
/usr/preserve -> /var/preserve
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
/var/spool/locks -> /var/lock
Most of the above symlinks should in time become unneeded as packages
are changed to support /var in addition to /usr. The exception, the
directory that should be referenced in /usr rather than /var is /usr/tmp
because some systems link it to different directories within /var.
The GNU Emacs lock file directory, if Emacs is installed, should be a
symlink pointing to /var/lock/emacs if you want to be able to mount /usr
read-only. It is usually found in /usr/emacs, /usr/lib/emacs, or
/usr/local/lib/emacs (preferably not the first).
5.1. /usr/X386 : X Window system on x86 platforms
This hierarchy is reserved for the use of XFree86 X11 releases.
- 18 -
Linux Filesystem Structure January 15, 1994
/usr/X386 : XFree86 installation directory
|- bin
|- doc
|- include
|- lib
+- man
To simplify matters and make X386 more compatible with other X11
packages, our recommendation is to place the following symbolic links on
your system:
/usr/bin/X11 -> /usr/X386/bin
/usr/lib/X11 -> /usr/X386/lib
/usr/include/X11 -> /usr/X386/include/X11
5.2. /usr/bin : Most user commands
/usr/bin : Binaries which are not needed in single-user mode.
|- mh : commands for the MH mail handling system
+- X11 : symlink to /usr/X386/bin
This is the primary directory of executable commands on the system.
5.3. /usr/dict : Word lists
REQUIRED files for /usr/dict:
{ words }
Traditionally this directory contains only the English `words' file,
which is used by look(1) and various spelling programs. `words' may use
either American or British spelling. Sites which need both around may
link `words' to /usr/dict/american-english or /usr/dict/british-english.
Another possible solution goes something like this:
$ cat american-english british-english | sort | uniq > words
Word lists for other languages may be added using the English name for
that language, e.g., /usr/dict/french, /usr/dict/danish, etc. These
should use the ISO 8859 character set appropriate for the language in
question; if possible the Latin1 (ISO 8859-1) character set should be
used.
The rationale behind having only word lists here is that they are the
only files used by all spell checkers. For example, ispell(1) uses a
complicated format for its "hashed dictionaries" that is only useful to
ispell and should thus go in /usr/lib/ispell.
- 19 -
Linux Filesystem Structure January 15, 1994
5.4. /usr/etc : site-wide system configuration
Storing configuration in /usr/etc for the software found in /usr/bin and
/usr/sbin is a problem. It makes the read-only mounting of /usr through
CD-ROM or NFS delivery very difficult at best. This is true for many of
the same reasons that /usr/tmp or /usr/spool/cron cause problems.
One possible solution that we considered was to completely eliminate
/usr/etc and specify that all configuration be stored in /etc. A
problem with this approach is that it does not properly anticipate the
possibility that many sites may want to have some configuration files
which are not machine-local.
We eventually decided that /etc should be the only directory which is
actually referenced by programs (that is, everything should look for
configuration in /etc and not in /usr/etc). Any configuration files
which need to be site-wide and are not needed either before /usr is
mounted (or in an emergency situation) should then be placed in
/usr/etc. Then, specific files (in /etc) on specific machines may or
may not be symbolically linked to appropriate configuration files
located in /usr/etc. This also means that /usr/etc is technically an
optional directory in the strictest sense, but we still expect all Linux
systems to incorporate it.
It is not recommended that symbolic links exist in /usr/etc that point
to files in /etc as is unnecessary and would interfere with local
control over machines which share a /usr directory.
5.5. /usr/include: Directory for standard #include files.
This is where all of the system's general-use include files should be
placed.
- 20 -
Linux Filesystem Structure January 15, 1994
/usr/include: include files.
|- X11 : Symlink to /usr/X386/include/X11
|- arpa : ARPAnet defined protocol definitions
|- asm : Symlink to /usr/src/linux/include/asm
|- bsd : BSD compatibility include files
|- gnu : GNU include files
|- linux : Symlink to /usr/src/linux/include/linux
|- net : Generic network-related definitions
|- netax25 : +AX25 (ARRL AX.25) specific definition
|- netinet : TCP/IP specific networking stuff
|- netipx : +IPX (Novell IPX/SPX) specific definitions
|- protocols : Protocol definitions (mostly INET-based)
|- readline : The GNU readline library
|- rpc : Sun Microsystems RCP definitions
|- rpcsvc : Sun Microsystems RCP service definitions
+- sys : System generation include files
5.6. /usr/lib : Libraries for programming and packages
/usr/lib : Libraries for programming and packages
|- X11 : Symbolic link to /usr/X386/lib
|- emacs : Support files for the GNU Emacs editor
|- groff : Libraries/directories for GNU groff
|- gcc-lib : System specific files/directories for `gcc'
|- mh : Libraries for the MH mail handling system
|- mf : Meta-Font data
|- news : Cnews/INN
|- smail : Smail
|- terminfo : Directories for terminfo database
|- tex : TeX (and LaTeX) data libraries
|- uucp : Commands for uucp
+- zoneinfo : Timezone information and configuration
The directory /usr/lib includes static data files and some internal
binaries like `sendmail'. `smail', if used, should be stored in
/usr/bin because both normal users and administrators will often want to
use it from the command line (/usr/lib/sendmail should also be linked to
/usr/bin/smail, of course).
5.7. /usr/local : Local directory
- 21 -
Linux Filesystem Structure January 15, 1994
/usr/local : Local directory
|- bin : Local only binaries
|- doc : Local Documentation
|- etc : Configuration for local only binaries
|- games : Locally installed games
|- lib : Libraries for /usr/local
|- info : Local info pages
|- man : Man page hierarchy for /usr/local
|- sbin : Local only system administration
+- src : Local source code
The /usr/local directory is used by the system administrator to install
software that needs to be safe from overwriting when the system software
is updated. It is used to store anything that is sharable among a group
of machines, but not found in /usr.
This directory should always be empty after first installing Linux, no
exceptions to this rule should be made other than the listed directory
stubs.
Locally installed software should be placed within /usr/local rather
than /usr unless it is being installed to replace or upgrade software in
/usr or it is felt that the installed software is "important enough" to
place in /usr or in /. Note that software placed in / or /usr will
often be overwritten with complete upgrades (unless proper backups are
made) therefore local software should not be placed in /usr/local
without good reason.
5.8. /usr/man : Manual pages
/usr/man : Manual page hierarchy
|- man1 : User programs
|- man2 : System calls
|- man3 : Library functions and subroutines
|- man4 : Devices
|- man5 : File formats
|- man6 : Games
|- man7 : Miscellaneous
|- man8 : System Administration
+- man9 : Kernel internal variables and functions
The cat page sections (cat[1-9]) containing formatted manual page
entries are also found within subdirectories of /usr/man, but are not
required nor should they be distributed in lieu of nroff source manual
pages.
Local and X Windows manual pages (if present) should be stored in
/usr/local/man and /usr/X386/man, respectively. These directories have
a similar structure to /usr/man (man[1-8], cat[1-8], empty
subdirectories being omitted).
- 22 -
Linux Filesystem Structure January 15, 1994
The MH mail handling system manual pages should have "mh" affixed to all
manual page filenames. X11 manual pages usually have "x" affixed to all
X11 manual pages.
As Linux (and UNIX) is further utilized in non-English speaking
countries and manual pages are translated to non-English versions, there
is the impending problem that these manual pages will have to be stored
somewhere else. Some German releases of Linux have already created a
manual page system that is placed in /usr/man with the suffix "g". This
is a poor solution and will cause further problems in the long run as
other languages appear, especially other languages starting with the
same letter (Greek, Gaelic, whatever).
Therefore, all non-English manual pages sections should be stored in
subdirectories within /usr/man named according to the language that the
the contained manual pages are written in (lowercase characters), hence,
for the German manual pages:
/usr/man/german/man[1-9] and possibly /usr/man/german/cat[1-9]
Then, German-speaking Linux users can add /usr/man/german to their
MANPATH before /usr/man so that /usr/man/german manual pages are
referenced first. If a German manual page is not found for a given
command then the English version may be referenced. This setup will be
needed as the number of foreign (non-English) manual pages increases.
German is the language mentioned here since it is the only non-English
manual page system distributed with any Linux system at this time.
Other languages will probably follow and they should follow this scheme
as well. We only use German as our example because it was the first
non-English manual system to be completed.
The practice of placing non-English in subdirectories of /usr/man should
be followed as well for other manual page hierarchies, such as
/usr/local/man and /usr/X11/man.
Note: Using the language itself (/usr/man/deutsch) rather than the
English (/usr/man/german) was considered, but this was met with
disapproval from many people, including those who do not speak English
as a first language. The reasons include: simplicity, the difficulty in
displaying many languages' names in ASCII characters, and the fact that
everyone should be able to recognize their language name in English.
A description of each section follows:
o man1: User programs
Manual pages that describe publicly accessible commands are
contained in this chapter. Most program documentation that a user
will need to use is located here.
o man2: System calls
This section describes all of the system calls which are entries
- 23 -
Linux Filesystem Structure January 15, 1994
to the Linux kernel (operating system). This section can be very
useful to programmers, but users have little need of the items in
section 2.
o man3: Library functions and subroutines
Section 3 describes user-level library routines. This is another
chapter that is only really of interest to programmers.
o man4: Special files
Section 4 describes the special files, related driver functions,
and networking support available in the system. Typically, the
device files found in /dev.
o man5: File formats
The formats for many nonintuitive data files are documented in the
section 5. This includes various include files, program output
files, and system files.
o man6: Games
This chapter documents games, demos, and generally trivial
programs. Different people have various notions about how
essential this is.
o man7: Miscellaneous
Manual pages that are difficult to classify are designated as
being section 7. The *roff and other text processing macro
packages are found here.
o man8: System administration
Documentation for programs used by system administrators for
system operation and maintenance are documented here. Some of
these programs are also occasionally useful for normal users.
o man9: Kernel internal variables and functions
This appears on Linux systems to document the kernel source code.
5.9. /usr/sbin : Non-vital standard system binaries
This directory contains any non-vital binaries used exclusively by the
system administrator (as root) which are not required for system repair
and recovery, mounting /usr, or other essential operations. This
includes networking daemons, large system administration tools, or
anything that really isn't needed.
Local system binaries and local administration shell scripts belong in
/usr/local/sbin.
- 24 -
Linux Filesystem Structure January 15, 1994
5.10. /usr/share : Architecture-independent data
Any specifications for /usr/share will be included in a supplementary
draft to the main FSSTND draft.
5.11. /usr/src : Source code
/usr/src : Source code
|
+- linux : Source code for Linus' kernel
Any non-local source code should be placed in this subdirectory. The
only source code that should always be placed in a specific location is
the kernel source (when present or linked in part to the /usr/include
structure). Subdirectories may be used here if desired.
The source code for the kernel should always be in place or at least the
include files from the kernel source. Those files are located in these
directories:
/usr/src/linux/include/asm
/usr/src/linux/include/linux
/usr/include usually contains links to `asm' and `linux' in the source
directory. Since they are needed by the C compiler, at least those
include files should always be distributed with installations. They
should also be distributed in the /usr/src/linux directory so there are
no problems when system administrators upgrade their kernel version for
the first time.
5.12. /usr/tmp : temporary files, used to keep /tmp small
Files in /usr/tmp are stored for an unspecified duration (please
remember that system temporary directories are not guaranteed to hold
data for any particular duration).
Data stored in /usr/tmp is typically cleaned out "in a site-specific
manner", but usually at less frequent intervals than /tmp. More
information on temporary directories is in the section of the draft
devoted to /tmp (above).
/usr/tmp is usually symlinked to /var/tmp.
- 25 -
Linux Filesystem Structure January 15, 1994
6. The /var directory
/var : Directories of files that tend to grow or vary in size
|- adm : System logging and accounting files
|- lock : Lock files
|- named : DNS files (for `named'), networking only
|- preserve : Saved text edited by `vi' after crash or hang-up
|- spool : Directories for queue work to be performed later
+- tmp : (symlink from /usr/tmp)
The directory for variable length files. This includes spools,
administrative files, logging files, transient files, and temporary
files.
A good reason to use /var is to make it possible to mount /usr read-
only. Everything that once went into /usr that is written to on a
temporary basis, now goes into /var. The aforementioned symbolic links,
also mentioned below in the issues and rationale section, should be
added to /usr for compatibility. This is very helpful if you are
mounting /usr through NFS or if you want a read-only /usr.
6.1. /var/adm : System logging and accounting files
All system logging should be written to this subdirectory and not to
/var/log. `wtmp' and `lastlog' should be stored here.
6.2. /var/lock : Lock files
Lock files should be stored within the /var/lock directory structure.
/var/lock : Lock files
+- emacs : Emacs lock files
To preserve the ability to mount /usr read-only, no lock files or lock
file systems should be stored on the /usr partition.
Device lock files, such as the serial device lock files which are found
in /usr/spool/locks or /usr/spool/uucp, should be stored in /var/lock.
The naming convention which should be followed is `LCK..{device}'. For
instance, if you are using a program which uses /dev/cua0, then it
should create a lock file, `/var/lock/LCK..cua0'. The contents of these
lock files should be the pid (process ID) of the process which is using
the device (stored in 7 bit ASCII), followed by a newline character.
Then, anything wishing to use /dev/cua0 can observe the lock file and
act accordingly.
Programs with large lock file systems should utilize a subdirectory of
/var/lock. For instance, GNU Emacs normally stores Emacs lock files in
/usr/lib/emacs/lock -- this poses a serious problem if you are trying to
- 26 -
Linux Filesystem Structure January 15, 1994
mount /usr read-only. Emacs lock files should instead be placed in
/var/lock/emacs.
If you are a developer/maintainer of an application which uses lock
files in any manner, it is a good idea to contact the FSSTND mailing
list or me to discuss the arrangement of your lock files.
At this time, lock files which are stored in /etc, such as pid lock
files, should remain in /etc.
6.3. /var/named : DNS and `named' stuff
This is only needed for systems running a DNS name server (networking
protocol for name servers).
6.4. /var/spool : Spool directories
The disputed definition of this directory is "queue work or work to be
done later". I suppose that more appropriately, it would be that plus
anything that wouldn't fit in /usr or seemed related to the original
stuff in here, but not always. Of course, that doesn't sound so great.
So... who has a real definition?
/var/spool : Spool directories
|- at : at jobs
|- cron : Cron jobs
|- lpd : Printer spool directory
|- mail : Directory for user mailboxes
|- mqueue : Outgoing mail queue
|- news : News spool directory
+- uucp : Spool directory for uucp
/var/spool/lpd : Printer spool directory
|- {printer} : Spools for a specific printer
+- {printer}.LOCK : Lock file for a specific printer
- 27 -
Linux Filesystem Structure January 15, 1994
7. Issues and Additional Rationale
This section discusses several areas that may require further
explanation.
7.1. What is Essential?
The answer is: essential to clean, create, prepare, check, find and
mount other filesystems (possibly on remote machines). There are other
definitions, but this is a general definition that most people will at
least incorporate into their own.
7.2. Networking
Networking presented an interesting dilemma. Some people wanted to
separate networking binaries and configuration from other binaries and
configuration. However, we disagree. We feel that networking is not a
"package", but an integral part of most UNIX (and UNIX-like) machines.
Because of this networking should not be placed into a single directory,
but systematically placed in the appropriate directories.
o /bin: anything a user will want to use that is also considered
vital
{hostname, netstat, ping, ...}
o /sbin: anything only root needs and is considered vital
{arp, ifconfig, ifsetup, route}
o /usr/bin: any binaries a user will want to use, but are not vital
{finger, rcp, rlogin, telnet, ...}
o /usr/sbin: any root only networking binaries that are not vital
{ftpd, inetd, lpd, telnetd, ...}
While this may seem confusing at first (and it does take a moment to
digest), it does make sense. If you can only mount root for some reason
and you need access to networking to repair your system, you don't need
the files to be off in /usr/etc (as they often are). Files that are
needed to mount /usr in normal (and emergency situations) are placed on
the root subtree and any others are placed in /usr in order to keep the
size of root small.
Configuration files for networking belong in /etc.
7.3. Architecture-independent Structures
Many people have noted that in this draft, that there was no /usr/share.
There is now. The structure, /usr/share, typically contains
- 28 -
Linux Filesystem Structure January 15, 1994
architecture-independent files such as man-pages, timezone, terminfo
information, et al. As of this time, there are no different
architectures for Linux, but with the passage of time we should see
Linux include other architectures and other UNIX-like systems.
One note, no program should ever reference anything in /usr/share. For
instance, a manual page program should never directly look in
/usr/share/man/man1/ls.1, but it should refer to /usr/man/man1/ls.1 at
all times. Anything in /usr/share will be "pointed-to" by the use of
symlinks from other areas in the filesystem, such as /usr/man,
/usr/lib/{something}, etc.
The specifications for /usr/share are still be worked out and discussion
within the FSSTND channel or with me is encouraged (by me).
7.4. Symbolic Links
There are a wide range of uses for symbolic links (symlinks) in every
filesystem. While symlinks are not encouraged for default setup (found
after installing Linux) in a standard such as this, they are often used
with good purpose on different systems. The point is that symlinks
should be there to keep everything where everyone else expects find it
Be prepared to accept that certain directories, even those contained on
the root directory, are still going to be symlinks. For instance, on
some systems /home will not be on the root, but symlinked to a /var
directory, or to somewhere else. /home could also have its own physical
partition, of course, and be mounted on its own.
Similarly, because /usr might be on a central file server mounted via
NFS, /usr/local could be symlinked to /var/local. Like /usr/emacs/lock,
this change can be justified by recalling one definition of /var:
"directories of files that vary on different systems and machines".
Sometimes systems will also link /tmp to /var/{something} if the root
partition becomes too small (or starts out too small). There are more
examples of "good" uses of symbolic links, but the entire issue boils
down to two things: packages should be able to find things where they
expect them (within reason) and symbolic links can be used to solve the
problem in many cases. However, problems also can arise from using too
many symbolic links. These problems include over-reliance on symbolic
links to solve problems, confusion resulting from overuse of symbolic
links, and the aesthetic preferences of different people.
7.5. Statically linked binaries
Linux is currently running on a wide variety of systems, some single
user with small disks, some as servers in large networked environments.
Because of this variety, this standard sets no rule regarding what
- 29 -
Linux Filesystem Structure January 15, 1994
binaries are static or dynamic with the following two exceptions. Both
`ln' and `sync' should exist in /bin; any statically linked versions may
be placed in /sbin, or replace those in /bin.
Large Linux systems may wish to include other statically linked binaries
(sh, init, mkfs, fsck, tunefs, mount, umount, swapon, swapoff, getty,
login, etc.). The developers and/or system administrators are free to
statically/dynamically link these and other binaries as they see fit, as
long as the location of the binaries doesn't change.
Networked systems (especially those of the future which may lack floppy
drives), may want to make ifconfig, route, hostname, and other
networking utilities static as well. This is usually not needed.
- 30 -
Linux Filesystem Structure January 15, 1994
The FSSTND mailing list
The FSSTND mailing list is located at linux-fsstnd@ucsd.edu. This list
was originally located on the linux-activists@Niksula.hut.fi "Mail-Net"
as the FSSTND channel. (To subscribe to the list send mail to
listserv@ucsd.edu with the body of "ADD linux-fsstnd".)
Thanks to the people at the University of California at San Diego who
allowed us to use their excellent mailing list server.
Acknowledgments
Credit for this text should be given to the FSSTND activists,
developers, system administrators, and users whose input was essential
to this standard. I also wish to thank each of the contributors who
helped me to write, compile, and compose this, a consensus standard.
I also wish to give real credit to those Linux developers who have seen
that giving Linux a common filesystem layout is something that will
further the development of the Linux operating system.
Original contributors
Drew Eckhardt <drew@kinglear.cs.colorado.edu>
Ian Jackson <ijackson@nyx.cs.du.edu>
Ian McCloghrie <ian@ucsd.edu>
Daniel J. Quinlan <quinlan@bucknell.edu>
Mike Sangrey <mike@sojurn.lns.pa.us>
David H. Silber <dhs@glowworm.firefly.com>
Theodore Ts'o <tytso@athena.mit.edu>
Stephen Tweedie <sct@dcs.ed.ac.uk>
- 31 -
Reference in New Issue View Git Blame Copy Permalink