14.1 Objective 1: Design a Hard
Disk Layout
Part of the installation
process for Linux is the design of the hard disk partitioning
scheme. If you're used to systems that reside on a single
partition, this step may seem to complicate installation.
However, there are advantages to splitting the filesystem into
multiple partitions, potentially on multiple disks. Details
about disks, partitions, and Linux filesystem top-level
directories are provided in Chapter
4. This Topic covers considerations for implementing Linux
disk layouts.
14.1.1 System Considerations
A variety of factors influence the choice of
a disk layout plan for Linux, including:
14.1.1.1 Limited disk space
Except for read-only filesystems (such as
CD-ROMs or a shared /usr partition), most Linux
filesystems should have some free space available. Filesystems
holding user data should be maintained with a generous amount
of free space to accommodate user activity. Unfortunately, if
there are many filesystems and all of them contain free space,
a significant portion of disk space could be considered
wasted. This presents a tradeoff between the number of
filesystems in use and the availability of free disk space.
Finding the right configuration depends on system requirements
and available disk resources.
When disk space is limited, it is desirable
to reduce the number of filesystems,
thereby combining free space into a single contiguous pool.
For example, installing Linux on a PC with only 1 GB of
available disk space might best be implemented using only a
few partitions:
- /boot
-
50 MB. A small /boot filesystem in
the first partition ensures that all kernels are below the
1024-cylinder limit.
- /swap
-
100 MB.
- /
-
850 MB. A large root partition holds
everything on the system that's not in /boot.
The /boot partition could be combined
with the root partition as long as
the entire root partition fits within the 1024-cylinder limit
(see Chapter
13).
On older systems with smaller hard drives,
Linux is often installed by spreading the directory tree
across multiple physical disks. This is no different in
practice than using multiple partitions on a single disk and
often encourages the reuse of older hardware. An additional
disk might be dedicated to /home in order to allow a
larger work area for the users' home directories.
14.1.1.2 Larger systems
On larger platforms, functional issues
such as backup strategies and required filesystem sizes can
dictate disk layout. For example, suppose a file server is to
be constructed serving 100 GB of executable datafiles to
end-users via NFS. Such as system will have enough resources
to compartmentalize various parts of the directory tree into
separate filesystems and might look like this:
- /boot
-
50 MB. Keep kernels under the 1024-cylinder
limit.
- /swap
-
100 MB.
- /
-
100 MB.
- /usr
-
1 GB. All of the executables in /usr
are shared to workstations via read-only NFS.
- /var
-
500 MB. By placing log files in their own
partition, they won't threaten system stability if the
filesystem is full.
- /tmp
-
100 MB. By placing temporary files in their
own partition, they won't threaten system stability if the
filesystem is full.
- /home
-
98 GB. This is the big filesystem, offered
to users for their home directories.
On production servers, much of the system is
often placed on redundant media, such as mirrored disks. Large
filesystems, such as /home, may be stored on some form
of disk array using a hardware controller.
14.1.1.3 System role
The role of the
system also can dictate disk layout. In a traditional
Unix-style network with NFS file servers, most of the
workstations won't necessarily need all of their own
executable files. In the days when disk space was at a
premium, this represented a significant savings in disk space.
While space on workstation disks isn't the problem it once
was, keeping executables on a server still eliminates the
administrative headache of distributing updates to
workstations.
14.1.1.4 Backup
Some backup schemes
use disk partitions as the basic unit of system backup. In
such a scenario, each of the filesystems listed in
/etc/fstab is backed up separately, and they are
arranged so that each filesystem fits within the size of the
backup media. For this reason, the available backup device
capabilities can play a role in determining the ultimate size
of partitions.
14.1.2 Swap Space
When you install
Linux, you're asked to configure a swap, or virtual
memory, partition. This special
disk space is used to temporarily store portions of main
memory containing programs or program data that is not needed
constantly, allowing more processes to execute concurrently.
An old rule of thumb for Linux is to set the size of the
system's swap space to be equal to the amount of physical RAM
in the machine. For example, if your system has 64 MB of RAM,
it would be reasonable to set your swap size to at least 64
MB. Another rule of thumb that predates Linux says swap space
should equal three times the main memory size. These are just
guidelines, of course, because a system's utilization of
virtual memory depends on what the system does and the number
and size of processes it runs. Using the size of main memory,
or thereabouts, is a good starting point.
Spreading swap space across multiple disk
drives can allow better swap performance because multiple
accesses can occur concurrently when multiple devices are
used. For even better performance, place those disks on
separate controllers, increasing bandwidth. For example, you
could place half of your planned swap space on each of two IDE
disks in your system. Those disks could be attached to the two
separate IDE interfaces.
14.1.3 General Guidelines
Here are some guidelines for
partitioning a Linux system:
-
Keep the root filesystem ( / ) small
by distributing larger portions of the directory tree to
other partitions. A small root filesystem is less likely to
be corrupted than a large one.
-
Separate a small /boot partition
below cylinder 1024 for kernels.
-
Separate /var. Make certain it is
big enough to handle your logs and their rotation scheme,
but not so large that disk space is wasted when the rotation
is filled.
-
Separate /tmp. Its size depends on
the demands of the applications you run. It should be large
enough to handle temporary files for all of your users
simultaneously.
-
Separate /usr and make it big enough
to accommodate kernel building. Making it standalone allows
you to share it read-only via NFS.
-
Separate /home for machines with multiple users.
For production use, put it on a disk array subsystem.
-
Set swap space around the same size as the
main memory. If possible, try to split the swap space across
multiple disks and controllers.
|
Since a disk layout is the product of
both system requirements and available resources, no
single example can represent the best configuration.
Factors to remember include placing the kernel below
cylinder 1024, ways to effectively utilize multiple
disks, sizing of partitions to hold various directories
such as /var and /usr, the importance of
the root filesystem, and swap space size. Also remember
the trick of splitting swap space across multiple
physical disks to increase virtual memory performance .
| 
|