Is that optimal? Recommended? Some would say that /home, /tmp,
/var
and others should reside in separate partitions/filesystems. Discuss. :-)
Better late than never...
I've recently come to the conclusion that for most stuff I do, skip LVM. LVM was great when resize2fs and gparted didn't exist. But with those tools now being so advanced, everything I cared to use LVM for is now handled in a much simpler way.
If you use LVM and still want to do resize type things in a way that LVM can't do (ran into this recently) then it's a major pain to work around LVM to use simple resize2fs commands.
That said, I still use the boot/root/swap 3 partition setup, as Fedora still likes it that way. Maybe separate boot isn't required anymore, but if it ain't broke, why fix it?
On my personal systems I do some other wacky stuff for performance reasons (splitting things on different disks for parallelism). So no harm to having separate /tmp or /var/spool/squid if disks permit.
If it's a system I care about, I'll do md RAID[16]. If it's a less important system (living room mythtv comp) then I'll just do 1 disk.
Adding another $0.02 to the mix (yeah, I know, I already expressed an opinion a while ago, now I've had time to think about it):
I find that the original rationale to keeing /root, /tmp, /var, etc all separate was to prevent users from filling up critical system partitions. This was in the day when a) most, if not all, UNIX systems had unprivileged users, and b) said systems died quite messily if the filesystem became completely full.
In my line of work, at least, I don't manage *even one single system* that has any unprivileged users, so the only person(s) filling up / or /var have access to do so as root if they choose.
Another rationale was due to the size and cost of disks - one typically wanted to purchase the minimum suitable amount of disk space, because over-buying disk space was ruinously expensive.
I can now purchase a 2TB disk drive for under $100. Even in SAS drives, the smallest disk obtainable today is 73GB. If you're throwing SSDs into the mix, or considering very high-performance environments where load-balancing is of concern, then separating partitions onto separate disks still makes sense.
A modern UNIX does not die catastrophically upon running out of disk space. It can definitely be a pain in the ass to recover from that situation, and if you wish to avoid any and all possibility of dealing with that headache, then by all means keep separate partitions/filesystems for high-growth-potential data.
Another rationale, related to the historical cost of acquiring disk storage, is that keeping all these filesystems separate makes it much easier to migrate them onto larger disks when the original disk fills up, without the need to migrate additional, unrelated filesystems to that new disk. Again, that situation just doesn't happen very often today (in my world), and with tools like resize2fs, it's largely irrelevant anyway.
Another rationale, under Linux and other i386-compatible unices, was to ensure that the system would always be bootable: older BIOSes could not load kernels from beyond cylinder 1024, so once whole-disk sizes increased beyond 1024 cylinders, even with geometry translation, a separate /boot partition was required to hold the kernel image so it could be loaded in real mode.
Any modern LBA-enabled BIOS can boot a kernel from any location on disk... at least up to the 2-point-something TB mark. If you're using 3TB+ disks (whether virtual or physical) then a separate boot partition might still be a good idea.
Another rationale, although somewhat newer, is that for 'hardened' systems, it's possible to mount everything except / with noexec, and in turn to mount / ro. (There are dozens of additional tweaks that can be done.) Run-of-the-mill commercial and personal systems are rarely that secure, and I don't work for an intelligence agency, nor do I work with so-called "high-value targets" or assets. If I need a system *that* secure, I just run OpenBSD instead of Linux and lock it down well. If I need to run an inherently insecure service on a system that needs to be secure, I design it to be a throwaway and use a VM environment to refresh the system from a snapshot nightly (or hourly...) so that despite it inevitably becoming compromised, I don't much care.
Arguing against these factors is supportability and sustainability. IF you have a dedicated admin team, who are all familiar with your custom filesystem layout, AND you have business continuity plans in place (which also implies your custom setup *and its rationale* is fairly well documented) then by all means go crazy optimizing your system to the Nth degree, which would imply not only a multitude of filesystems but also custom mkfs parameters, custom TCP stack sysctls, carefully hand-crafted configuration files, a custom selinux policy... etc, etc, etc. And you're also using a custom-compiled Gentoo, right? Or maybe you compiled your own distro from scratch. :-)
In my opinion, even RHEL's default of / + /boot + swap over LVM is too complicated, although it has the distinct advantage of being "standard", and legions of systems in existence today use that layout.
In my world of DNS, DHCP, LDAP, RADIUS, etc. servers, keeping separate filesystems provides no benefit. Using LVM provides no benefit. I create a single root partition, generally using ext3fs, either on hardware RAID or on MD RAID. (Oh, and there's another reason to keep a separate /boot: neither LILO nor GRUB can boot directly off any kind of software RAID except RAID 1. So if / is RAID[03456] you need a separate /boot partition.) I create a swap partition if the application seems to require any swap.
If I were a lab administrator, for example, with unprivileged - and often untrusted - users abusing the systems every day, my decisions would be vastly different. I do use different layouts for mail servers and sometimes for database servers, for example, because they have more complex requirements.
In all cases I aim for "hands-off" management, and simplicity of management - when I have to log into a system to determine what's wrong, I want to deal with the smallest possible number of variables, because my "time is money". So a single root partition, no swap, no LVM, no /boot, makes diagnosis easier. It doesn't always make resolution *faster* but it usually narrows down the option space to the point where I can come up with one, or two top recommendations to solve the problem almost immediately. That makes it easier to get buy-in from whoever I'm working for. (It also makes it easier to come to clear decisions in my own mind, because my default inclination is make things too complicated.)
YMMV.
-Adam Thompson athompso@athompso.net