From: Wolfgang.Draxinger on
Am Mon, 26 Apr 2010 16:12:39 +0000 (UTC)
Alan Mackenzie <acm(a)muc.de>:

> Er, one like me? The recommendation used to be (perhaps still is)
> setting up distinct partitions for things
> like /usr, /var, /home, /tmp, /boot, /swap, and
> even /var/spool/mail, /usr/local, ..... You don't have to be
> installing many installations before you hit that 15 partition
> limit. Indeed with a near-infinite number of partitions available
> (63, 64?) who worries too much about eeking out their partitions?

This recommendation dates back to the days where hard disks were so
small, that -- in theory -- a process running havoc could render your
system unusable within minutes by filling up the disk. This never
happened to me though.

But what I did ran into very commonly was, that one of the partitions
got full due to normal operations, so that critical processes got
stalled, or I was unable to ran system updates, because in the time
where both new and old versions of libraries, binaries, etc. are in the
system at the same time I ran out of space.

Nowadays, when installing new systems the boot disk gets two
partitions: One for the bootloader and a small emergency initramfs
image system. And one huge /

Non bootdisks don't get partitions at all, they're formated right on
the unpartitioned block device level - either as Linux RAID devices, or
just with a file system on them. I'm doing it that way now for >5 years,
never run into problems with runaway processes trashing space, and have
a lot fewer headaches since then.

Also new file systems like ZFS and BtrFS allow you to set up slices,
which give you all the benefits of partitions (separation of working
spaces) with the benefits of a real filesystem, like instant resizing.


Wolfgang