Re: Advantage of partitioning?
From: Rod Smith (rodsmith_at_nessus.rodsbooks.com)
Date: Fri, 25 Jul 2003 14:52:41 -0400
In article <firstname.lastname@example.org>,
email@example.com (Bill Unruh) writes:
> Nico Kadel-Garcia <firstname.lastname@example.org> writes:
> ]Guylene Gadal wrote:
> ]>>Can someone explain the advantage of partitioning the HD? Why wouldn't I
> ]>>just want a swap and leave the rest as /? I don't understand why some
> ]>>install docs say to set up different partitions like this:
> ]>>/boot 35 Meg
> No idea why. A very bad idea. When you install your next kernel,
> suddenly /boot is full.
Two compiled Linux kernels won't fill a 35MB partition, at least not in
2003. Of course, if you keep a big collection of kernels, 35MB might
become inadequate. As with all questions regarding partitioning,
appropriate values are *VERY* system-dependent (and by extension,
administrator-dependent). What works well for System A may be terrible
for System B.
> Unleass you have a pre 1998 computer (ie the bios has the 8GB limit on
> reading) just leave /boot in /
This certainly works for many people. There are reasons to separate it,
though. You mentioned one, although it's becoming increasingly rare.
Another is to keep the boot files on a simple filesystem that's well
understood by most boot managers, while giving yourself the flexibility
of using something more advanced for the root filesystem. (I don't know
offhand just what filesystems might cause problems for GRUB or LILO right
now. It used to be they were rather limited, but they've been improving
recently. Some Mac systems work well with HFS /boot partitions, in order
to let certain MacOS boot loaders read the kernel.) Another potential
reason is to provide a way to separate the critical kernel file from the
heavily-accessed root filesystem, in order to protect against filesystem
corruption or accidental file deletion. In fact, the documentation for
Gentoo recommends not mounting /boot at all except when you need to
update the kernel.
> ]>>/usr 2048+ Meg
> 5GB so there is room for all the extra software you want to install.
The precise value depends on the administrator's/user's needs and
> ]>>/var 1500+ Meg
> ]>>/tmp 1024 Meg
> Never could understand these. They are easily cleaned out if you run out
> of room. I just leave them in /. /var there may be some justification
> for as it is the spool directories, etc.
These might be separated to keep high-activity directories on separate
partitions, as insurance against filesystem errors and the like, or even
to help split the disk-access load across physical disks. There may also
be advantages to using different filesystems for some of these. For
instance, a news server might benefit from having /var use a filesystem
that copes well with lots of small files, like ReiserFS. If you prefer to
use something that's not as good with small files for the root
filesystem, splitting /var off onto a separate partition makes sense.
Also, I've heard of people who like to mount the root filesystem
read-only, necessitating that all directories that need read/write access
(such as /var and /tmp) be put on separate partitions. The idea is that a
read-only root (with read-only /etc) is that much harder to abuse or
accidentally delete. Of course, other measures SHOULD prevent such abuse
or accidents, but sometimes these other measures are unintentionally
misconfigured, there's a bug, etc.
> ]>>/ 1024 Meg
> ]>>/home grow to fill disk
> Depends of if you use home more than say /usr/local.
This is critical. Every system's different. I've seen good arguments for
all sorts of partitioning systems in specific situations. In another
situation, something else will work better. The merits of a given system
can be debated endlessly, but the value of such debates is limited
without reference to a specific system and usage pattern.
> ]>>I understand the concept of setting up the partitions, I just can't
> ]>>understand why I would want to. It seems to me that when one of these
> ]>>mounts runs out of space I've shot myself in the foot. If I just left it
> ]>>with one partition as / I wouldn't run into that problem.
> But the next time you need to upgrade your OS, you would understand.
> HOw do you backup a 120MB partition?
I assume you mean 120GB, not 120MB. In answer:
- Multiple tapes (or other removable media), manually swapped in.
- A tape changer.
- A big removable hard disk.
- Depending on the data, using heavy compression might cram it onto
something substantially smaller.
Overall, I do agree that a clever partitioning system can greatly simplify
backup and recovery. Personally, I try to keep certain partitions
(particularly certain non-Linux partitions) under 700MB, so that I can fit
them onto a single CD-R; or at worst, under ~1400MB, so I can do the same
with compression. This is getting pretty hard, though.
-- Rod Smith, email@example.com http://www.rodsbooks.com Author of books on Linux, FreeBSD, and networking