Very Computer

    Gilles> I was wondering what are the advantages on using a
    Gilles> separate swap partition as opposed to a swapfile on the
    Gilles> Linux partition. I have one 2.1 GB HD therefore both the
    Gilles> swap partition and Linux partition will be on the same
    Gilles> drive.  --

RTFM: Swap partition is much faster cos' it the kernel won't have to
go through the fs layer to swap.

Phil.

True, but using a swapfile is more flexible. If you decide you need more
swap space (or if your services require more swap space) later on, you
can just increase the swapfile size. However, if your swap partition
turns out to be inadequate, then you're hosed if you don't have any
un-partitioned space left over.

--
--Rob
---------------------------------------------------------------------------
Robert Tsai                        http://rtsai.student.harvard.edu/~rtsai/

Quote:> True, but using a swapfile is more flexible. If you decide you need more
> swap space (or if your services require more swap space) later on, you
> can just increase the swapfile size. However, if your swap partition
> turns out to be inadequate, then you're hosed if you don't have any
> un-partitioned space left over.

--


Publib http://www.iki.fi/liw/publib/

You can always start with a swap partition and supplement it with a swap
file when the need arises.  That way you get the speed benefit of the
swap partition until it fills up.

--

--
A. Sanda
Vienna, Austria                              

------------------------------------------------------------------

Quote:>:: RTFM: Swap partition is much faster cos' it the kernel won't have to
>:: go through the fs layer to swap.
>file when the need arises.  That way you get the speed benefit of the
>swap partition until it fills up.

PeterJordan

Quote:>So should I be putting /home /usr /bin and so on on their own partitions ?

(plus, if you're running a multiuser system, setting quotas on /home
only is simpler if it's got its own fs. then, you likely want
/var/spool or maybe all of /var on its own device too.)
--
   "I'm more differed from than differing"   --  Arthur Dent

    >>> RTFM: Swap partition is much faster cos' it the kernel won't
    >>> have to go through the fs layer to swap.
    >>  True, but using a swapfile is more flexible. If you decide you
    >> need more swap space (or if your services require more swap
    >> space) later on, you can just increase the swapfile
    >> size. However, if your swap partition turns out to be
    >> inadequate, then you're hosed if you don't have any
    >> un-partitioned space left over.

    Robert> You can always start with a swap partition and supplement
    Robert> it with a swap file when the need arises.  That way you
    Robert> get the speed benefit of the swap partition until it fills
    Robert> up.

Yup.
I've even seen a swapd daemon* somewhere at sunsite which will
create and use swap files when virtual memory is going low, and
releasing it (and erasing the files) when VM gets high again... quite
nice...

Phil.

There are several things to take into considerations when you
decide how to partition you disk and where to put these
partitions.

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
   swap.

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
   "thrashing".

   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
   access speed.

   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
   faster, though.

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
   "Operating Systems".

   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
   less.

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
   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 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
   partition.

   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 »

: >:: RTFM: Swap partition is much faster cos' it the kernel won't have to
: >:: go through the fs layer to swap.

: >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 ?

/home and /use are fine.  Actually, I made /home a symbolic link to
/usr/home, and just put /usr on a separate disk.

BOT DON'T MOVE /BIN OR YOU COULD HOSE YOURSELF IN A BIG WAY!  I can't
stress this enough.  You want /bin, /etc, /sbin, /lib, and /lib-aout (if
you have one) part of your root partition, along with /root (root's home
directory).  Oh, and leave /boot too.  If you don't, you could be in
serious trouble if any of your filesystems has bas fsck problems.

--------
If you can lead it to water and force it to drink, it isn't a horse.

Got a Linux problem?  Or can you help others solve them?  Visit the Linux
Common Problems page at http://vortex.cc.missouri.edu/~rhys/linux.html

That is totally unrelated to the question of swap partition vs. swap file.
There are arguments for putting /home and /usr on separate file systems:

 /home:  Keep the users' files on their own file system away from the
         system files.  That limits the scope of the problem when the
         users fill up their file system.

 /usr:   Files in /usr are not written to in normal operation.  The file
         system can even be mounted read-only (provided /usr/tmp is a
         mount point or a symbolic link elsewhere, such as to /var/tmp).

Another candidate for a separate file system is /var.

You must *not* put /bin on a separate file system.  The system won't
boot properly unless the programs in /bin are available when only the
root file system is mounted.  The same goes for /sbin, /lib, /etc, and
/dev.  It is also a good idea to keep root's home directory on the root
file system.

The major argument _against_ separate file systems is that your free
space becomes fragmented.

--

Quote:>:So should I be putting /home /usr /bin and so on on their own partitions ?

>That is totally unrelated to the question of swap partition vs. swap file.
>There are arguments for putting /home and /usr on separate file systems:

--

 _                                _                               _

|r|      Finger => PGP etc       |g|  Carnegie Mellon University |l|
|_|   http://www.snurgle.org/    |e|   rynrynrynrynrynrynrynryn  |_|