388 lines
8.3 KiB
HTML
388 lines
8.3 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Background</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux System Administrators Guide"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Overview of the Directory Tree"
|
|
HREF="dir-tree-overview.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Overview of the Directory Tree"
|
|
HREF="dir-tree-overview.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="The root filesystem"
|
|
HREF="root-fs.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Linux System Administrators Guide: </TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="dir-tree-overview.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 3. Overview of the Directory Tree</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="root-fs.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="FS-BACKGROUND"
|
|
></A
|
|
>3.1. Background</H1
|
|
><P
|
|
>This chapter is loosely based on the <I
|
|
CLASS="CITETITLE"
|
|
>Filesystems
|
|
Hierarchy Standard</I
|
|
> (FHS).
|
|
version 2.1, which attempts to
|
|
set a standard for how the directory tree in a Linux
|
|
system is organized. Such a standard has the advantage that it will
|
|
be easier to write or port software for Linux, and to administer
|
|
Linux machines, since everything should be in standardized places.
|
|
There is no authority behind the standard that forces anyone to
|
|
comply with it, but it has gained the support of many Linux
|
|
distributions. It is not a good idea to break with the FHS without
|
|
very compelling reasons. The FHS attempts to follow Unix tradition
|
|
and current trends, making Linux systems familiar to those with
|
|
experience with other Unix systems, and vice versa.</P
|
|
><P
|
|
>This chapter is not as detailed as the FHS. A system
|
|
administrator should also read the full FHS for a complete
|
|
understanding.</P
|
|
><P
|
|
>This chapter does not explain all files in detail. The
|
|
intention is not to describe every file, but to give an overview of
|
|
the system from a filesystem point of view. Further information on
|
|
each file is available elsewhere in this manual or in the Linux
|
|
manual pages.</P
|
|
><P
|
|
>The full directory tree is intended to be breakable into
|
|
smaller parts, each capable of being on its own disk or partition,
|
|
to accommodate to disk size limits and to ease backup and other
|
|
system administration tasks. The major parts are the root
|
|
(<TT
|
|
CLASS="FILENAME"
|
|
>/</TT
|
|
>
|
|
),
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/usr</TT
|
|
>
|
|
,
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/var</TT
|
|
>
|
|
, and
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/home</TT
|
|
>
|
|
filesystems
|
|
(see <A
|
|
HREF="fs-background.html#FSTREE"
|
|
>Figure 3-1</A
|
|
>). Each part has a
|
|
different purpose. The directory tree has been designed so that it
|
|
works well in a network of Linux machines which may share some parts
|
|
of the filesystems over a read-only device (e.g., a CD-ROM), or over
|
|
the network with NFS.</P
|
|
><DIV
|
|
CLASS="FIGURE"
|
|
><A
|
|
NAME="FSTREE"
|
|
></A
|
|
><P
|
|
><B
|
|
>Figure 3-1. Parts of a Unix
|
|
directory tree. Dashed lines indicate partition
|
|
limits.</B
|
|
></P
|
|
><P
|
|
><IMG
|
|
SRC="fstree.png"></P
|
|
></DIV
|
|
><P
|
|
>The roles of the different parts of the directory tree are
|
|
described below.
|
|
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>The root filesystem
|
|
is specific for
|
|
each machine (it is generally stored on a local disk,
|
|
although it could be a ramdisk or network drive as well) and
|
|
contains the files that are necessary for booting the system
|
|
up, and to bring it up to such a state that the other
|
|
filesystems may be mounted. The contents of the root
|
|
filesystem will therefore be sufficient for the single user
|
|
state. It will also contain tools for fixing a broken
|
|
system, and for recovering lost files
|
|
from backups.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The <TT
|
|
CLASS="FILENAME"
|
|
>/usr</TT
|
|
>
|
|
filesystem
|
|
contains all commands, libraries, manual pages, and other
|
|
unchanging files needed during normal operation. No files in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/usr</TT
|
|
> should be specific for any given
|
|
machine, nor should they be modified during normal use. This
|
|
allows the files to be shared over the network, which can be
|
|
cost-effective since it saves disk space (there can easily
|
|
be hundreds of megabytes, increasingly multiple gigabytes in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/usr</TT
|
|
>). It can make administration
|
|
easier (only the master <TT
|
|
CLASS="FILENAME"
|
|
>/usr</TT
|
|
> needs to
|
|
be changed when updating an application, not each machine
|
|
separately) to have /usr network mounted. Even if the
|
|
filesystem is on a local disk, it could be mounted
|
|
read-only, to lessen the chance of filesystem corruption
|
|
during a crash.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The <TT
|
|
CLASS="FILENAME"
|
|
>/var</TT
|
|
>
|
|
|
|
filesystem contains files that change, such as spool
|
|
directories (for mail, news, printers, etc), log files,
|
|
formatted manual pages, and temporary files. Traditionally
|
|
everything in <TT
|
|
CLASS="FILENAME"
|
|
>/var</TT
|
|
> has been somewhere
|
|
below <TT
|
|
CLASS="FILENAME"
|
|
>/usr</TT
|
|
>
|
|
, but that made it
|
|
impossible to mount <TT
|
|
CLASS="FILENAME"
|
|
>/usr</TT
|
|
> read-only.
|
|
</P
|
|
><P
|
|
></P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The <TT
|
|
CLASS="FILENAME"
|
|
>/home</TT
|
|
>
|
|
|
|
filesystem contains the users' home directories, i.e., all
|
|
the real data on the system. Separating home directories to
|
|
their own directory tree or filesystem makes backups easier;
|
|
the other parts often do not have to be backed up, or at
|
|
least not as often as they seldom change. A big
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/home</TT
|
|
> might have to be broken across
|
|
several filesystems, which requires adding an extra naming
|
|
level below <TT
|
|
CLASS="FILENAME"
|
|
>/home</TT
|
|
>, for example
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/home/students</TT
|
|
> and
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/home/staff</TT
|
|
>.</P
|
|
></LI
|
|
></UL
|
|
> </P
|
|
><P
|
|
>Although the different parts have been called filesystems
|
|
above, there is no requirement that they actually be on separate
|
|
filesystems. They could easily be kept in a single one if the
|
|
system is a small single-user system and the user wants to keep
|
|
things simple. The directory tree might also be divided into
|
|
filesystems differently, depending on how large the disks are, and
|
|
how space is allocated for various purposes. The important part,
|
|
though, is that all the standard <EM
|
|
>names</EM
|
|
> work;
|
|
even if, say, <TT
|
|
CLASS="FILENAME"
|
|
>/var</TT
|
|
>
|
|
and
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/usr</TT
|
|
>
|
|
are actually on the same partition, the names
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/usr/lib/libc.a</TT
|
|
> and
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/var/log/messages</TT
|
|
> must work, for example by
|
|
moving files below <TT
|
|
CLASS="FILENAME"
|
|
>/var</TT
|
|
> into
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/usr/var</TT
|
|
>, and making <TT
|
|
CLASS="FILENAME"
|
|
>/var</TT
|
|
>
|
|
a symlink to
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/usr/var</TT
|
|
>.</P
|
|
><P
|
|
>The Unix filesystem structure groups files according to
|
|
purpose, i.e., all commands are in one place, all data files in
|
|
another, documentation in a third, and so on. An alternative would
|
|
be to group files files according to the program they belong to,
|
|
i.e., all Emacs files would be in one directory, all TeX in another,
|
|
and so on. The problem with the latter approach is that it makes it
|
|
difficult to share files (the program directory often contains both
|
|
static and sharable and changing and non-sharable files), and
|
|
sometimes to even find the files (e.g., manual pages in a huge
|
|
number of places, and making the manual page programs find all of
|
|
them is a maintenance
|
|
nightmare).</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="dir-tree-overview.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="root-fs.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Overview of the Directory Tree</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="dir-tree-overview.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>The root filesystem</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |