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 Large-disk
HOWTO for details.
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.
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.
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 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.
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.
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 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?).
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.