Newsgroups: comp.unix.wizards
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Why Partition a Hard Disk
Message-ID: <1988Aug31.174144.1694@utzoo.uucp>
Organization: U of Toronto Zoology
References: <4360004@wdl1.UUCP>
Date: Wed, 31 Aug 88 17:41:44 GMT

In article <4360004@wdl1.UUCP> jeff@wdl1.UUCP (Jonathan J Jefferies) writes:
>Is there any definitive reason to partition a hard disk?

The original reason for partitioning was 16-bit limits on the number of
blocks in a file system.  This has long since ceased to be an issue.
The one significant resource limitation that remains in some systems is
16-bit inode numbers, limiting the number of files that can exist in a
single filesystem.  4BSD has fixed this, but at least the early System V
releases didn't (I'm not sure about the current ones).

On multi-user systems, sometimes it can be useful to have more than one
partition so that a group can be told "you've got all of partition 3,
fight it out among yourselves if space gets short there".

These things aside, the major reason for partitioning is damage limitation.
On some systems, it is absolutely necessary that the root filesystem be
relatively small, because fsck must be able to do a consistency check on
the root with all its tables fitting into main memory.  Having a separate
root filesystem is not a bad idea anyway, because it's very vital and the
less it changes, the less chance of it getting fouled up.  Taking this to
the opposite extreme, giving /tmp its own filesystem can be useful, because
it puts a very active area off by itself where it can't mess up anything
else.  (This can also be useful to spread disk traffic over multiple drives.)

A number of security holes also become harder to exploit if users are not
allowed to write anywhere in the "system" file systems.  The benefits of
this have been somewhat eroded by things like symbolic links, however.
A related issue is that splitting system and users means that runaway
user programs can't fill up the system filesystems, and vice-versa.

Many Unix systems do backups on a partition basis, so if you want to apply
different backup policies to different sets of files, there has to be a
partition boundary between them.

Supporting diskless workstations off a central file server can involve a
major song-and-dance with partitions, depending on who wrote the software.

If none of these considerations apply, the fewer the partitions the better.
It is better to have one big free-space pool than a lot of little ones that
can't help each other out when one gets low.

(Us?  Utzoo as currently operational has two Eagles.  Each has two or three
small partitions and one enormous one that occupies most of the disk.  The
two enormous ones are /usr and /zoo (our users).  We use little ones for
root, swap, /tmp, and a small work area for news archiving.)
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu