Disk partitioning and swap

[mikebw at bilow.bilow.uu.ids.net (Mike Bilow)]

Jerry Feldman wrote in a message to Mike Bilow:

 JF> I would like to see some discussion on the advantages and
 JF> disadvantages of allocating 1 large file system in contrast
 JF> to having some small ones.  One restriction is the location
 JF> of the kernel, but a small /boot partition could be
 JF> allocated for this. In the olden days of small disks, root,
 JF> usr, var, and home would be allocated on separate disks. But
 JF> today with multi-GB drives in the pocket money range, does
 JF> it make sense to follow the old Unix model. 

My view is that there are few reasons to use lots of little filesystems.  You
get all sorts of complexities if you try to use quotas or hard links, and
multiple filesystems are generally harder to back up using standard tools such
as tar.  I do commonly make two filesystems, one for /home and one for
everything else, when building servers intended to widely accessed, such as
with Samba, but this meshes neatly with quota and backup policies.

The downside to having large filesystems is that errors or corruption can
render the system totally unusable.  For a very high reliability system, it
might make sense to have the stuff required to boot on one filesystem and
everything else on another filesystem, but high reliability systems tend to
have everything that is on them classified as critical, which makes this
pointless.  The proper way to handle to case of filesystem corruption is by
backing up regularly, not by playing foolish filesystem tricks.  Also, Linux
has nice RAID software facilities now which would actually benefit from having
large filesystems, since they can be mirrored or duplexed onto separate disks.

 JF> Also, what is the cost of swapping to the root file system
 JF> rather than allocating a separate swap partition. 

This is a controversy.  My view is that the largest cost of disk access, by
far, is head motion.  If you make a separate swap partition, then you tend to
maximize head motion and therefore increase swap overhead.  Also, for IDE
disks, switching from one hardware disk to another on the same physical channel
is very expensive, so it is desirable to have the swap area on the MOST
frequently used filesystem.

Again, the downside to using a swap file instead of a swap partition is that
you are not guaranteed that the swap area will be contiguous on the media.  As
a practical matter, if you make the swap file shortly after system installation
and you make it an integral mulltiple of 8 MB (when using ext2fs), then it will
very likely be contiguous and almost certainly have no more than one
discontinuity.

Note that some distributions, such as Red Hat, will not install without a swap
partition.  Debian has a very convenient way of handling this by assuming that
you know what you are doing, but most others do not.  Even with Red Hat, where
you are forced to make a swap partition, you can later allocate a swap file and
assign it a stronger priority than the swap partition.

 JF> I am asking this question more in context of the new Linux
 JF> users who are migrating from the Windoz environment rather
 JF> than from the experienced Linux user. Also, we have an
 JF> Installfest coming up on May 1, and I would like to use some
 JF> guidelines. 
 JF> Let's take an example:
 JF> We have 4GB available for Linux on a drive which may be
 JF> shared with Windoz. 
 JF> Question 1, what is the cost of an extended partition vs. a
 JF> primary partition. (You can only allocate 4 primary
 JF> partitions on a physical drive). 

No brainer: you cannot boot from an extended partition (except with OS/2). 
There is no difference in access time for a primary or extended partition,
since the extra overhead for chasing down the physical location on the media,
which is only one disk access anyway, is only done once at mount time.

 JF> Question 2. Using this scenario:
 JF> Partition 1: /boot 100MB (for vmlinux, and modules) Linux
 JF> Native Partition 2: swap (depends on memory size. I normally
 JF> allocate maximum, but I think that the newer kernels have 
 JF> eliminated that restriction).
 JF> Partition 3: Root - Rest of disk.

There's no good reason to keep /boot off by itself, unless you have a machine
with some funny BIOS limitation, such as not being able to handle drives larger
than 512 MB, where you must do tricks like this to make Lilo happy.  Such a
configuration is unnecessarily complicated to maintain, in my opinion.  To be
useful, this little partition must have everything needed for booting, which
includes /boot, /lib/, /etc, /bin, /sbin, and possibly even some other stuff
such as /root (for disaster recovery).  For a machine with LBA support in the
BIOS, LBA should be enabled and a small boot partition is not needed.

 JF> What are the main advantages/disadvantages of this
 JF> allocation scheme in contrast to (something similar to ):
 JF> Partition 1: root+usr (500 MB)
 JF> Partition 2: swap
 JF> Partition 3: /var (Depends on intended use)
 JF> Partition 4: /home (Depends on intended use). 

 JF> If the intended use is a mail server, I would probably have
 JF> a large /var for spool and logs. If this is used as a
 JF> multi-user platform with a number of users, then the /home
 JF> would be rather large.

There is no good reason to make /var separate like this, unless the rest of the
filesystem, particularly /usr, is going to be remotely mounted using a network
protocol such as NFS.  Technically, /var is by definition the component which
cannot be shared, which is why is it so named.  For very complicated
installations, where /usr or other major parts of the filesystem are mounted
from a remote source, then /var should be separate and a series of other
changes also need to be made.  However, for anyone likely to come to an
Installfest, I can't imagine worrying about this.

I mentioned earlier that I often do allocate /home on its own partition when
the number of user accounts will be large.  In most systems, however, the
number of user accounts will be small, and a separate /home is wasteful.

 JF> Question 3: If we use extended partitions, should swap be in
 JF> a primary or is there no significant performance issue.   

There is no significant performance issue.  Although there is a very slight
performance penalty for an extended partition when "mount" or "swapon" is
executed, there is no performance penalty thereafter.
 
-- Mike


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).