New HOWTO: Linux Partition HOWTO - page 5

Table of Contents

4. Partitioning requirements

4.1. What Partitions do I need?

Boot Drive: If you want to boot your operating system from the drive you are
about to partition, you will need:

  * A primary partition
   
  * One or more swap partitions
   
  * Zero or more primary/logical partitions
   
Any other drive:

  * One or more primary/logical partitions
   
  * Zero or more swap partitions

-----------------------------------------------------------------------------
4.2. Discussion:

Boot Partition:
    Your boot partition ought to be a primary partition, not a logical
    partition. This will ease recovery in case of disaster, but it is not
    technically necessary. It must be of type 0x83 "Linux native". If you are
    using lilo, your boot partition must be contained within the first 1024
    cylinders of the drive. (Typically, the boot partition need only contain
    the kernel image.)
   
    If you have more than one boot partition (from other OSs, for example,)
    keep them all in the first 1024 cylinders (All DOS partitions must be
    within the first 1024). If you are using a means other than lilo loading
    your kernel (for example, a boot disk or the LOADLIN.EXE MS-DOS based
    Linux loader), the partition can be anywhere. See the [http://
    metalab.unc.edu/mdw/HOWTO/Large-Disk-HOWTO.html] Large-disk HOWTO for
    details.
   
Swap Partition:
    Unless you swap to files you will need a dedicated swap partition. It
    must be of type 0x82 "Linux swap".  It may be positioned anywhere on the
    disk (but see notes on placement: Section 4.4.2). Either a primary or
    logical partition can be used for swap. More than one swap partition can
    exist on a drive. 8 total (across drives) are permitted. See notes on
    swap size: Section 4.4.1.
   
Logical Partition:
    A single primary partition must be used as a container (extended
    partition) for the logical partitions. The extended partition can go
    anywhere on the disk. The logical partitions must be contiguous, but
    needn't fill the extended partition.

-----------------------------------------------------------------------------
4.3. File Systems

4.3.1. Which file systems need their own partitions?

Everything in your linux file system can go in the same (single) partition.
However, there are circumstances when you may want to restrict the growth of
certain file systems. For example, if your mail spool was in the same
partition as your root fs and it filled the remaining space in the partition,
your computer would basically hang.

/var
    This fs contains spool directories such as those for mail and printing.
    In addition, it contains the error log directory. If your machine is a
    server and develops a chronic error, those msgs can fill the partition.
    Server computers ought to have /var in a different partition than /.
   
/usr
    This is where most executable binaries go. In addition, the kernel source
    tree goes here, and much documentation.
   
/tmp
    Some programs write temporary data files here. Usually, they are quite
    small. However, if you run computationally intensive jobs, like science
    or engineering applications, hundreds of megabytes could be required for
    brief periods of time. In this case, keep /tmp in a different partition
    than /.
   
/home
    This is where users home directories go. If you do not impose quotas on
    your users, this ought to be in its own partition.
   
/boot
    This is where your kernel images go. If you use MSDOS, which must go in
    the first 1024 cylinders, you need to at least get this partition in
    there in order to ensure that [http://metalab.unc.edu/mdw/HOWTO/mini/
    LILO.html] lilo can see it. If you have a drive larger than 1024
    cylinders, making this your first partition guarantees that it will be
    visible to lilo.
   
-----------------------------------------------------------------------------
4.3.2. File lifetimes and backup cycles as partitioning criteria

With ext2, partitioning decisions should be governed by backup considerations
and to avoid external fragmentation (Section 7.3) from different file
lifetimes.

Files have lifetimes. After a file has been created, it will remain some time
on the system and then be removed. File lifetime varies greatly throughout
the system and is partly dependent on the pathname of the file. For example,
files in /bin, /sbin, /usr/sbin, /usr/bin and similar directories are likely
to have a very long lifetime: many months and above. Files in /home are
likely to have a medium lifetime: several weeks or so. File in /var are
usually short lived: Almost no file in /var/spool/news will remain longer
than a few days, files in /var/spool/lpd measure their lifetime in minutes or
less.

For backup it is useful if the amount of daily backup is smaller than the
capacity of a single backup medium. A daily backup can be a complete backup
or an incremental backup.

You can decide to keep your partition sizes small enough that they fit
completely onto one backup medium (choose daily full backups). In any case a
partition should be small enough that its daily delta (all modified files)
fits onto one backup medium (choose incremental backup and expect to change
backup media for the weekly/monthly full dump - no unattended operation
possible).

Your backup strategy depends on that decision.

When planning and buying disk space, remember to set aside a sufficient
amount of money for backup! Unbackuped data is worthless! Data reproduction
costs are much higher than backup costs for virtually everyone!

For performance it is useful to keep files of different lifetimes on
different partitions. This way the short lived files on the news partition
may be fragmented very heavily. This has no impact on the performance of the
/ or /home partition.
-----------------------------------------------------------------------------

4.4. Swap Partitions

4.4.1. How large should my swap space be?

If you have decided to use a dedicated swap partition, which is generally a
Good Idea [tm], follow these guidelines for estimating its size:

  * In Linux RAM and swap space add up (This is not true for all Unices). For
    example, if you have 8 MB of RAM and 12 MB swap space, you have a total
    of about 20 MB virtual memory.
   
  * When sizing your swap space, you should have at least 16 MB of total
    virtual memory. So for 4 MB of RAM consider at least 12 MB of swap, for 8
    MB of RAM consider at least 8 MB of swap.
   
  * Currently, the maximum size of a swap partition is
    architecture-dependent. For i386 and PowerPC, it is approximately 2Gb. It
    is 128Gb on alpha, 1Gb on sparc, and 3Tb on sparc64. For linux kernels
    2.1 and earlier, the limit is 128Mb. The partition may be larger than 128
    MB, but excess space is never used. If you want more than 128 MB of swap
    for a 2.1 and earlier kernel, you have to create multiple swap
    partitions. See the man page for mkswap for details.
   
  * When sizing swap space, keep in mind that too much swap space may not be
    useful at all.

A very old rule of thumb in the days of the PDP and the Vax was that the size
of the [partition-3.html#swap] working set of a program is about 25% of its
virtual size. Thus it is probably useless to provide more swap than three
times your RAM.

But keep in mind that this is just a rule of thumb. It is easily possible to
create scenarios where programs have extremely large or extremely small
working sets. For example, a simulation program with a large data set that is
accessed in a very random fashion would have almost no noticeable locality of
reference in its data segment, so its working set would be quite large.

On the other hand, an xv with many simultaneously opened JPEGs, all but one
iconified, would have a very large data segment. But image transformations
are all done on one single image, most of the memory occupied by xv is never
touched. The same is true for an editor with many editor windows where only
one window is being modified at a time. These programs have - if they are
designed properly - a very high locality of reference and large parts of them
can be kept swapped out without too severe performance impact.

One could suspect that the 25% number from the age of the command line is no
longer true for modern GUI programs editing multiple documents, but I know of
no newer papers that try to verify these numbers.

So for a configuration with 16 MB RAM, no swap is needed for a minimal
configuration and more than 48 MB of swap are probably useless. The exact
amount of memory needed depends on the application mix on the machine (what
did you expect?).
-----------------------------------------------------------------------------

4.4.2. Where should I put my swap space?

  * Mechanics are slow, electronics are fast.
   
    Modern hard disks have many heads. Switching between heads of the same
    track is fast, since it is purely electronic. Switching between tracks is
    slow, since it involves moving real world matter.
   
    So if you have a disk with many heads and one with less heads and both
    are identical in other parameters, the disk with many heads will be
    faster.
   
    Splitting swap and putting it on both disks will be even faster, though.
   
  * Older disks have the same number of sectors on all tracks. With these
    disks it will be fastest to put your swap in the middle of the disks,
    assuming that your disk head will move from a random track towards the
    swap area.
   
  * Newer disks use ZBR (zone bit recording). They have more sectors on the
    outer tracks. With a constant number of rpms, this yields a far greater
    performance on the outer tracks than on the inner ones. Put your swap on
    the fast tracks.
   
  * Of course your disk head will not move randomly. If you have swap space
    in the middle of a disk between a constantly busy home partition and an
    almost unused archive partition, you would be better of if your swap were
    in the middle of the home partition for even shorter head movements. You
    would be even better off, if you had your swap on another otherwise
    unused disk, though.
   
Summary: Put your swap on a fast disk with many heads that is not busy doing
other things. If you have multiple disks: Split swap and scatter it over all
your disks or even different controllers.

Even better: Buy more RAM.
-----------------------------------------------------------------------------