pjor...@gpu4.srv.ualberta.ca (Peter Jordan) writes:
>>file when the need arises. That way you get the speed benefit of the
>>swap partition until it fills up.
>So should I be putting /home /usr /bin and so on on their own partitions ?
This is something completely different.
There are several things to take into considerations when you
decide how to partition you disk and where to put these
HOW LARGE SHOULD MY SWAP SPACE BE?
Regarding swap partitions there are the following guidelines:
1. 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.
2. 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
3. When sizing swap space, keep in mind that too much swap space
may not be useful at all.
Every process has a "working set". This is a set of in-memory
pages which will be referenced by the processor in the very
near future. Linux tries to predict these memory accesses
(assuming that recently used pages will be used again in the
near future) and keeps these pages in RAM if possible. If the
program has a good "locality of reference" this assumtion
will be true and Linux prediction algorithm will work.
Holding a working set in main memory does only work if there
is enough main memory. If you have too many processes running
on a machine, the kernel is forced to put pages on disk that
it will reference again in the very near future (forcing a
page-out of a page from another working set and then a
page-in of the page referenced). Usually this results in a
very heavy increase in paging activity and in a sustantial
drop of performance. A machine in this state is said to be
On a thrashing machine the processes are essentially running
from disk and not from RAM. Expect performance to drop by
approximately the ratio between memory access speed and disk
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?).
WHERE SHOULD I PUT MY SWAP SPACE?
1. 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
2. Older disks have the same number of sectors on all tracks.
With this 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.
3. 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.
4. 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.
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.
HOW SHOULD I PARTITION MY DISK?
1. Disk space is administered by the operating system in units
of blocks and fragments of blocks. In ext2, fragments and
blocks have to be of the same size, so we can limit our
discussion to blocks.
Files come in any size. They don't end on block boundaries.
So with every file a part of the last block of every file is
wasted. Assuming that file sizes are random, there is
approximately a half block of waste for each file on your
disk. Tanenbaum calls this "internal fragmentation" in
You can guess the number of files on your disk by the number
of allocated inodes on a disk. On my disk
# df -i
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda3 64256 12234 52022 19% /
/dev/hda5 96000 43058 52942 45% /var/spool/news
there are about 12000 files on / and abou 44000 files on
news. At a block size of 1 KB, about 6+22 = 28 MB of disk space
are lost in the tail blocks of files. Had I chosen a block
size of 4 KB, I had lost 4 times this space.
Data transfer is faster for large contiguous chunks of data,
though. That's why ext2 tries to preallocate space in units
of 8 contigous blocks for growing files (unused preallocation
is released when the file is closed).
Noncontigous placement of blocks in a file is bad for
performance, since files are often accessed in a sequential
manner. It forces the operating system to split a disk access
and the disk to move the head. This is called "external
fragmentation" or simply "fragmentation" and is a common
problem with DOS filesystems. ext2 has several strategies to
avoid external fragmentation.
ext2 does not force you to choose large blocks for large file
systems (except for very large filesystems in the 0.5 TB range
and above, where small block sizes become inefficient). So
unlike DOS there is no need to split up large disks into
multiple partitions to keep block size down. Use the 1 KB
default block size if possible. You may want to experiment with
a block size of 2 KB for some partitions, but expect to meet
some seldom exercised bugs: Most people use the default.
With ext2, Partitioning decisions should be governed by backup
considerations and to avoid external fragmentation from
different file lifetimes.
2. Files have lifetimes. After a file has been created, it will
remain some time on the system and them 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
3. 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 exspect to change
backup media for the weekly/monthly full dump - no unattended
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 that
backup costs for virtually everyone!
4. 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
A common model creates /, /home and /var partitions as
discussed above. This is simple to install and maintain and
differentiates well enough to avoid adverse effects from
different lifetimes. It fits well into a backup model, too:
Almost noone bothers to backup USENET news spools and only
read more »