Partitioning strategies (was Re: [TriLUG] partitioning: primary or logical)

[rpjday]

On 15 May 2002, Ben Pitzer wrote:

> Okay, I'll open this up to the general public.  I have two disks in my
> Debian box, and to be perfectly honest, unless you are mounting multiple
> disks, I find it very wasteful to overpartition a hard drive.  Creating
> partitions like this was a way to use multiple disks within a system,
> each for a filesystem.  For the average user, I find that a single /
> partition, or perhaps a /boot and a / in the case of RH or Mandrake
> users, is usually sufficient.  I came to this conclusion in painful
> ways.  First, if all the partitions are on one disk, it doesn't make a
> difference in terms of disk error recovery.  If the disk has a bad
> sector, that's one thing, but how often these days does that happen? 
> Typically, the entire disk fails, in which case having multiple
> partitions won't make that much of a difference.  Am I wrong about
> this?  I don't have much experience with data recovery (and how much
> would that cost the average user anyway?  Is it worth it to get your old
> email from Gramma?)
> 
> Additionally, I found that I was misappropriating my paritions.  Too
> often, I would overuse one partition quickly, and run out of space
> there, yet only be using tiny portions of my other partitions.  Thus,
> while the disk would only be 30-40% used, I would be at 98% on one
> partition.  Granted, that's the fault of the partitioner, however it's
> just easier, less complicated, and less likely to cause problems if I
> just have fewer partitions.
> 
> Any thoughts on this?  I really think that there is very little wrong
> with creating just a / and swap, or a /boot, root and swap partition in
> the majority of cases.
> 
> Regards,
> Ben Pitzer

Rationale for multiple partitions:

1)  You're looking at data recovery the wrong way.  It's not hardware-
based disk failure that should concern you.  It's when the machine
halts unexpectedly and possibly corrupts the filesystem structure.
With multiple filesystems, it's more likely to isolate any corruption
in a single filesystem.

2)  Minimally, you should create a separate /home partition.  What
this does is gives you the option of installing a new version of
Linux over top of the old one but preserving the entire /home
partition and just re-mounting it at /home while partitioning in
Disk Druid (if you're in Red Hat).  Note that, if you choose to do
this, you do have to also preserve the config files /etc/passwd,
/etc/group and /etc/shadow so you can restore them later, but this
is easy.  (Naturally, you can always just back up the /home 
directory and restore it after the install, but it just seems
easier to leave all the data where it is.)

3)  If you have multiple partitions, you've effectively limited
the amount of data that can be dumped into the corresponding
directory.  Users have a bad habit of downloading all sorts of
junk, but at least you can guarantee that they can't collectively
overflow the /home directory if it's a separate partition.
Similarly, a runaway process that keeps filling up a file can't 
overflow the entire root directory and halt the machine if that
file is in a separate partition.  Above all, you want to make
sure that, no matter what happens elsewhere in the directory
structure, the root directory and /tmp should be protected from
accidental overflow, and separate partitions let you do this.

4)  After you've installed, if you're ambitious, you can go
back and reformat the individual filesystems with different
attributes depending on what they're going to hold.  Look
at the "mke2fs" command: you can use it to rebuild an ext2
filesystem with differing ratios for inode to data block,
with differing reserved space for the superuser, differing
logical block sizes and so on.  So reformat each filesystem 
to be appropriate for what it will contain to be as efficient
as possible.

5)  Separate filesystems can be mounted with separate attributes
for greater security.  "man mount":  you might want to mount
filesystems read-only, allow users to mount some of them,
mount them nodev, noexec and so on.  You can't get this kind
of flexibility if they're just separate directories. 

6) Separate filesystems can also be shared amongst multiple
Linux installs on the same host.  If you want a dual-boot box
with both Red Hat 7.2 and 7.3, you can install them separately
but they might share some filesystems, perhaps /usr/local/bin.

  And, finally, this problem with misapportioning of the 
initial filesystem sizes.  You can beat this if you first
install with nothing but / and swap, then boot, login and
run "du -ks /*".  This will show you precisely how much
space is used under all the top-level directories.  And now
that you know, you re-install having a much better idea of
how much space you'll need, taking into account which of
those filesystems will grow and which won't.  In effect,
the first install is a throwaway just so you can learn
from it.  I've done this for years, and never had a
problem.

  (And if you really do run out of space in a filesystem,
you can always cheat and use symlinks to steal space from
another filesystem -- something else I've never had to do.)

  Filesystems are your friends.

rday