Tom Rauschenbach <[EMAIL PROTECTED]> effectivly asks why to bother to
distribute sections of the file system across multiple partitions and
drives, and what schemes are desireable:
One reason to carve up the file system is to divide partitions
among separate drives to enhance performance. If the drives are of
differing performance, then putting the more heavily accessed
partitions (swap, demand paged application binaries, active data base
files, temporary files) on the faster drive makes sense. If the
drives are of similar performance, and their interfacing and usage
allows some parallelism in access, for example writing pages to the
swap partitiong, paging in an application text page, and reading
and/or writing data blocks for one or more processes waiting on I/O
simultaneously. Caching, read ahead, and write behind strategies
implemented onboard modern drives can provide some of these advantages
even in the face of choke points like connecting multiple drives via
single synchronous interfaces of drivers too stupid to take advantage
of avalable interface asynchronous access capabilities.
Special useage which bypasses the filesystem code can make a
separate partition desireable. Some other system takes responsibility
for the management of the use of blocks within a pre-allocated fixed
sized hunk of disk space. Swap is an example. It need not go through
the filesystem code that translates a file offset to a partition
offset by walking through inode data structures in order to start a
read or write. It can implement allocation strategies which maximize
the probability of reads and/or writes of contiguous disk blocks,
minimizing seeking and it's attendent performance hits, and maximizing
the benefit of drive caching and read ahead strategies. Some
specialized applications have kept large data files in private
partitions without filesystems for similar reasons, a few high end
data bases being common current examples, but swap is the only example
that most of us will see on our machines. Access to underlying disk
address, which something in kernel, like the swapper/pager can
obviously arrange, and the probability of large chunks of contiguous
allocation in a file created early in a filesystem's history, makes
these kinds of optimizations possible with swapping to a file, rather
than to a partition (with the added advantage of making it possible
for the swap space to grow dynamicly), but there are non-performace
related reasons to put swap in a separate partition anyway, see below.
Another reason to have multiple partitons is its impact on
backup strategy. Some partitions, such as swap, tmp, and some
strategies for the use of var (do you care about long term retention
of your logs?), may never need to be backed up, or just once (to
restore the directory structure on var, for example). Some partitions
have content which changes infrequently, and then by not much. usr
excluding usr/local is an example. root and boot are others. While
there is no reason to reduce the frequency of incremental backups for
these partitions, full backups, which should be periodic in any
reasonable backup strategy, can be much less frequent for these
partitions. While backup software could be clever enough to allow
such distinctions among files or sub-directories within a filesystem,
the traditional backup tools make such distinctions on a filesystem by
filesystem basis.
tmp never needs to be fsck'ed.
Activly written filesystems have a greater potential for being
damaged in a crash or due to disk errors. The size of the data set on
infrequently written partitions affects the rate at which they are
written, and therefore the probability of damage. This makes it wise
to separate files critical to reparing a broken system live in
separate, infrequently written partitions. Examples are / or, if
separate, / and boot.
Upgrade strategy suggests that home and, if your chosen
distribution is kind enough not to use it, usr/local, be separate
partitions. Since replacing things file by file is error prone,
distribution upgrades want to wipe filesystems like boot, root, and
usr, and populate them from scratch. This strategy also maximizes the
contiguousness of application binaries, improving application startup
time. If the distribution's upgrade software is kind and cleverly
written, you won't have to restore your home directory and local
applications afterwards. (Things like rpm databases sorting out what
was installed to usr/local via an rpm are a separate problem.)
Another possible benefit of separate home and usr local is the
possibility of having more than one distribution installed, so that
you can try them out, without having to duplicate your home
directories and local applications.
Sharing the machine with another operating system typically
requires partitioning. Linux is (probably?) capable of running from
within a foreign filesystem (say, treating a FAT partition as a umsdos
partition) if the filesystem in question is built into the kernel,
rathern than being a module. But most or all distributions fail to
make this easy to set up.
The shortcommings of the combination of LILO, certain older
BIOS features, and the design of the original PC/AT hard disk
controler, conspire to make us want our kernel files to live with the
first (in some space) 1024 "cylendars". (Does anyone know if things
like the "linear" lilo keyword now fix this even for older hardware?)
This means that the stuff currently in boot must live on a partition
that is entirely contained within the first 1024 cylendars of (the
BIOS representation of) its disk (at least for IDE). boot can be left
as a part of /, but then / in its entirety must live within the first
1024 cylendars. Windows seems particularly nasty in demanding that it
boot from the first partition of the first drive (at least I've never
gotten anything else to work). This seems to mean that at best your
Windows C: drive needs to be smaller than the 1024 cylendar limit
(about 2GB at best?) by enough to completely hold the partition
containing boot. Since minimum comfortable C: drive sizes get larger
every few weeks (lots of large software seems to work poorly if not
installed on C:), one wants to get as close to the 1024 cylendar limit
as possible, so in turn one wants the partiton containing boot to be
as small as possible, and thus its own partition. One can get around
the limitation on Windows drive C: by putting boot on a second drive,
if you have one (not on this laptop), with which lilo and linux are
quite happy. (Note that one boot will serve for multiple linux
installations on the same box, since the root partition is specified
either with rdev in the kernel image booted, or via its lilo passed in
command line, which in turn leads to fstab, so you can have a separate
filesystem layout depending on which lilo tag or extra root argument
you specify.)
The big downside to partitioning things is that the relative
sizes of the partition are pretty well fixed once you've installed
(though some of the newer partition managers and tools are addressing
this if you are willing to shut down during the adjustment). This
means that, if you guess wrong about the sizes that you use, you can
run out of space on a filesystem even though there is plenty of room
on the disk. You can deal with this (even in the absence of fancy
partition managers) using symbolic links, but it is still a head
scratcher manual operation. The problem never would have happened if
the partition that filled and one with lots of space had been a single
partition in the first place.
Since disks are so big these days, and since I don't seem to
have developed any taste for acquiring boatloads of multi-media stuff,
my choice is to partition freely. My typical partition set is: /,
boot, var, usr, usr/local, home, dos, and maybe tmp (or this may be
part of var).
Bill
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
