[RndTbl] Partitioning in Linux

Adam Thompson athompso at athompso.net
Mon Jul 11 17:06:45 CDT 2011


> > 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 at athompso.net





More information about the Roundtable mailing list