Characteristics of the UNIX filesystem:
– A hierarchical structure
– Consistent treatment of file data
– Protection of file data
Two categories of file data:
– Shareable vs. Unshareable
– Static vs. Variable
Shareable data is that which can be shared between multiple systems.
Example: User Home Directories: /home
Unsharable data is that which is specific to a particular host.
Example: Device lock files. Or even better /etc.
Static data included binaries, libraries, documentation, or anything
else that does not change without system administration intervention.
Variable data is anything that changes without system administration
intervention. Example: /var/log
For ease of backup, administration, sharing of data on Heterogeneous
networks, there must be a easy to understand mapping from directories
to the data they contain.
The distinction between shareable and unshareable data is needed for
-In a networked environment (i.e., more than one host at a site),
there is a good deal of data that can be shared between different
hosts to save space and ease the task of maintenance.
-In a networked environment, certain files contain information specific
to a single host. Therefore these filesystems cannot be shared
(without taking special measures).
-Historical implementations of UNIX-like filesystems interspersed
shareable and unshareable data in the same hierarchy, making it
difficult to share large portions of the filesystem.
The “shareable” distinction can be used to support, for example:
-A /usr partition (or components of /usr) mounted (read-only) through
the network (using NFS).
-A /usr partition (or components of /usr) mounted from read-only media.
-A CD-ROM can be considered a read-only filesystem shared with other
FHS-compliant systems, using the postal mail system as a “network”.
The “static” versus “variable” distinction affects the filesystem in
two major ways:
-Since / contains both variable and static data, it needs to be mounted
-Since the traditional /usr contains both variable and static data, and
since we may 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 that 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.
Here is a summarizing chart. Since this chart contains generalized
examples, it may not apply to every possible implementation of an
Table 2.1 The root file system
The contents of the root filesystem should be adequate to boot, restore, recover, and/or repair the system. – To boot a system, enough must be present on the root partition to
mount other filesystems. This includes utilities, configuration,
boot loader information, and other essential start-up data. /usr,
/opt, and /var are designed such that they may be located on other
– To enable recovery and/or repair of a system, those utilities needed
by an experienced maintainer to diagnose and reconstruct a damaged
system should be present on the root filesystem.
– To restore a system, those utilities needed to restore from system
backups (on floppy, tape, etc.) should be present on the root
The root filesystem should be kept as small as possible. Reasons:
– It is occasionally mounted from very small media.
– The root filesystem has many system-specific configuration files in
it. Possible examples include a kernel that is specific to the
system, a different hostname, etc. This means that the root
filesystem isn’t always shareable between networked systems. Keeping
it small on networked systems minimizes the amount of space lost on
servers to unshareable files. It also allows workstations with
smaller local hard drives.
– While you may have the root filesystem on a large 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 root filesystems on
smaller partitions. If you are a developer then you may be turning
your assumption into a problem for a large number of users.
– Disk errors that corrupt data on the root filesystem are a greater
problem than errors on any other partition. A small root filesystem
is less prone to corruption as the result of a system crash.
*** Software should never require a directory be added to the root
filesystem. There are other filesystems used for this purpose.
There are several reasons why introducing a new subdirectory of the
root filesystem is prohibited:
– It demands space on a root partition which the system administrator
may want kept small and simple for either performance or security
– It evades whatever discipline the system administrator may have set
up for distributing standard file hierarchies across mountable
/ The root directory – 1st major hierarchy
bin Essential Command Binaries
boot Static files of the boot loader
dev Device Files
etc Host-specific system configuration
home User home directories
lib Essential shared libraries and kernel modules
mnt Mount point of temporary partitions
opt Add-on application software packages
root Home directory for the root user
sbin Essential System binaries
tmp Temporary files
usr Secondary Hierarchy
var Variable Data
Must be on root:
– Contains commands used by system administrators and users, but are
required in single user mode.
– May contain commands indirectly used by scripts.
– Should never contain subdirectories.
– Should be a directory below the root.
m- Contains everything required to boot the system except configuration
files and the map installer.
– The operating system kernel should be in / or /boot.
– configuration files should be /etc.
– contains special or device files.
– Should contain the command MAKEDEV which is used to manually create
devices. Should be setup to make any device.
– Contains files and directories that are specific to the local system.
– No binaries should be stored in this directory.
– Contains X-Windows configuration files for the local system.
– Contains XF86Config configuration file and directories which contain system files for each window manager.
– Contains machine specific information for the applications installed under /opt.
– Suggested location for user home directories. This is optional. You can place anywhere you like.
– Software developers should not assume user home directories are stored here.
– Can be divided into groups, i.e. /home/marketing, /home/engineering, etc.
– Contains libraries that are essential to boot the system and to run commands from the root filesystem.
– Contains loaded kernel modules.
– Shared libraries that are required by /usr do not belong in /lib.
– Contains libraries that are required by commands located in /bin and /sbin.
– Temporary mount point for temporary filesystems.
– /mnt/floppy – Mount point for /dev/fd0 (floppy drives)
– /mnt/cdrom – Mount point for /dev/cdrom (cdrom drive)
– Storage area for optional or add-in software packages.
– Packages should be stored in /opt/
– Any information specific to the local machine should be stored in /etc/opt.
– Any variable data used by the package should be stored in /var/opt.
– Traditional location for root’s home directory is /.
– The reason for moving to /root or /home/root is reduce the clutter in the / directory.
– Commands used by root only are stored in /sbin, /usr/sbin, and /usr/local/sbin.
– /usr/local/sbin contains commands specific to the local machine.
– Users should have read and execute permissions to the files in /sbin except suid or sgid utilities.
– The separations of utilities are not for security purposes. Only purpose is to separate user commands from root only commands.
– Directory used to store temporary files created by programs.
– Contents should be deleted whenever the machine is rebooted.
– Programs should not assume that files created in this directory would be kept between sessions.
/usr – Second Major Hierarchy
– Is a shareable filesystem.
– Should be mounted read-only.
– Most user commands
– Include files needed for C or C++ programming languages.
– Stores object files, libraries, and internal binaries which are not intended to be executed by users or shell scripts.
– All architecture dependant software for an application should be stored in a directory beneath /usr/lib. Example: /usr/lib/perl5.
– Miscellaneous architecture-independent application-specific static files and subdirectories should be placed in /usr/share.
– Contains software used by the system administrator when installing software on the local machine.
– Contains non-essential system administrator commands. Commands which are not required to repair the filesystems or mount a filesystem.
– Contains network daemons, non-essential administration tools, and non-critical server tools.
– Architecture independent software is stored here.
– This path is sharable via networked hosts which contain the same operating system version but may be running on different microprocessors, i.e. i386, alpha, sparc, etc.
– Any non-local source code should be stored here.
– /usr/src/linux is where the linux source code is stored.
/var – third hierarchy
– Contains variable data.
– This includes spool directories, administration log files and transient files.
– Some directories are not shareable because they contain data specfic to the local machine. These include /var/log, /var/lock, and /var/run.
– Others like /var/mail and /var/spool/news can be shared.
– If /var can not be made a separate partition, it is prefered that it be moved out of the / partition to save space. It can be moved under /usr.
/var/account – Accounting information if supported.
/var/cache – Application cached data.
/var/games – Variable game data such as high score records.
/var/lock – Contain lock files (indicate that a device is in use)
/var/opt – Application variable files for apps stored in /opt.
/var/yp – Store database files for Sun’s Network Information Services (NIS).
/var/state – Contains state information for applications or local system
– /var/state/ contains information, for example, stored by `vi` or some other editor. If the system crashes, `vi` will be able to restore your file to the state it was before the system crashed.
/var/spool – Application spool directory
– Most important is /var/spool/lpd which temporary stores data being spooled to a local or remote printer.
– Contains information about the system since it was booted.
– Process identifier files are stored in the format
.pid. For example, if cron was running you would have cron.pid in /var/run.
/var/log – System log files
– lastlog – stores the last login of every user.
– messages – stores system messages and errors.
– wtmp – record of all logins and logouts.
/var/mail – User mailbox files