><IMG
SRC="tip.gif"
HSPACE="5"
ALT="Tip"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Rationale</B
></TH
></TR
><TR
><TD
> </TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Shareable files can be stored on one host and used on several
others. Typically, however, not all files in the filesystem
hierarchy are shareable and so each system has local storage
containing at least its unshareable files. It is convenient if all
the files a system requires that are stored on a foreign host can be
made available by mounting one or a few directories from the foreign
host.</P
><P
>Static and variable files should be segregated because static
files, unlike variable files, can be stored on read-only media and
do not need to be backed up on the same schedule as variable
files.</P
><P
>Historical UNIX-like filesystem hierarchies contained both
static and variable files under both <TT
CLASS="FILENAME"
>/usr</TT
> and
<TT
CLASS="FILENAME"
>/etc</TT
>. In order to realize the advantages
mentioned above, the <TT
CLASS="FILENAME"
>/var</TT
> hierarchy was
created and all variable files were transferred from
<TT
CLASS="FILENAME"
>/usr</TT
> to <TT
CLASS="FILENAME"
>/var</TT
>.
Consequently <TT
CLASS="FILENAME"
>/usr</TT
> can now be mounted read-only
(if it is a separate filesystem). Variable files have been
transferred from <TT
CLASS="FILENAME"
>/etc</TT
> to
<TT
CLASS="FILENAME"
>/var</TT
> over a longer period as technology has
permitted.</P
><P
>Here is an example of a FHS-compliant system.
(Other FHS-compliant layouts are possible.)</P
><DIV
CLASS="INFORMALTABLE"
><P
></P
><A
NAME="AEN103"
></A
><TABLE
BORDER="1"
FRAME="hsides"
CLASS="CALSTABLE"
><COL><COL><COL><THEAD
><TR
><TH
><SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
></I
></SPAN
></TH
><TH
>shareable</TH
><TH
>unshareable</TH
></TR
></THEAD
><TBODY
><TR
><TD
>static</TD
><TD
>/usr</TD
><TD
>/etc</TD
></TR
><TR
><TD
> </TD
><TD
>/opt</TD
><TD
>/boot</TD
></TR
><TR
><TD
>variable</TD
><TD
>/var/mail</TD
><TD
>/var/run</TD
></TR
><TR
><TD
> </TD
><TD
>/var/spool/news</TD
><TD
>/var/lock</TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="THEROOTFILESYSTEM"
></A
>Chapter 3. The Root Filesystem</H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="PURPOSE2"
>Purpose</A
></H2
><P
>The contents of the root filesystem must be adequate to boot,
restore, recover, and/or repair the system.</P
><P
></P
><UL
><LI
STYLE="list-style-type: disc"
><P
>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.
<TT
CLASS="FILENAME"
>/usr</TT
>, <TT
CLASS="FILENAME"
>/opt</TT
>, and
<TT
CLASS="FILENAME"
>/var</TT
> are designed such that they may be located
on other partitions or filesystems.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>To enable recovery and/or repair of a system, those utilities
needed by an experienced maintainer to diagnose and reconstruct a
damaged system must be present on the root filesystem.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>To restore a system, those utilities needed to restore from
system backups (on floppy, tape, etc.) must be present on the root
filesystem.</P
></LI
></UL
><DIV
CLASS="TIP"
><P
></P
><TABLE
CLASS="TIP"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="tip.gif"
HSPACE="5"
ALT="Tip"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Rationale</B
></TH
></TR
><TR
><TD
> </TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>The primary concern used to balance these considerations, which
favor placing many things on the root filesystem, is the goal of
keeping root as small as reasonably possible. For several reasons, it
is desirable to keep the root filesystem small:</P
><P
></P
><UL
><LI
><P
>It is occasionally mounted from very small media.</P
></LI
><LI
><P
>The root filesystem contains many system-specific configuration
files. Possible examples include a kernel that is specific to the
system, a specific hostname, etc. This means that the root filesystem
isn't always shareable between networked systems. Keeping it small on
servers in networked systems minimizes the amount of lost space for
areas of unshareable files. It also allows workstations with smaller
local hard drives.</P
></LI
><LI
><P
>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.</P
></LI
><LI
><P
>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.</P
></LI
></UL
></TD
></TR
></TABLE
></DIV
><P
>Applications must never create or require special files or
subdirectories in the root directory. Other locations in the FHS
hierarchy provide more than enough flexibility for any package.</P
><DIV
CLASS="TIP"
><P
></P
><TABLE
CLASS="TIP"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="tip.gif"
HSPACE="5"
ALT="Tip"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Rationale</B
></TH
></TR
><TR
><TD
> </TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>There are several reasons why creating a new subdirectory of
the root filesystem is prohibited:</P
><P
></P
><UL
><LI
STYLE="list-style-type: disc"
><P
>It demands space on a root partition which the system
administrator may want kept small and simple for either performance or
security reasons.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>It evades whatever discipline the system administrator may have
set up for distributing standard file hierarchies across mountable
volumes.</P
></LI
></UL
><P
>Distributions should not create new directories in the root
hierarchy without extremely careful consideration of the consequences