Prev: irq affinity & DELL power edge r610
Next: Now, my Debian thinks I have SCSI for my old IDE/ATA drives after installing Kernel 2.6.32-4?
From: Wolfgang.Draxinger on 6 May 2010 05:29 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 |