[vox-tech] Need Partitioning Advice

[Bill Broadley]

While I realize this is a religious issue and everyone has their own idea I
think it's a particularly bad idea to as Karsten's page says make the basic
recommendation for 6 partitions.  If you read his page it looks like he's
pretty strong on /boot and swap partitions as well.  So yes I think a basic
recommendation for 8 partitions is insane.  You just end up with a labor
intensive fragile system that requires a substantial amount of specialized
knowledge to create and is rather sensitive to any future changes to the system.

First let me say that for any particular use that a there can be a small gain
by using small partitions.  Say putting of of the 8 partitions on the fastest
part of the disk, or skipping a journal, mounting read only, etc.  No argument
for a particular metric you can make a difference.

The flip side is that it requires specialized knowledge (quick, what's the
optimal /var, /usr, /usr/local for a particular distribution? ) that's often
basically unknowable.  Can you really guess how many packages you are going to
install in /usr/local in the next 3 years?  Can you really afford to
periodically "spend a day rationalizing your partition sizes?".  What actual
real world benefit justifies losing a man day periodically?  Did you notice
that even after the "day of rationalization" he still had to make symlinks
between partitions to handle overflow?

Sure when Unix boxes were hugely expensive, CPU cycles are precious
commodities, OS's were primitive, disks hugely expensive, security was
terrible (plain text passwords, buffer overflows, no selinux/apparmor,
commonly all network services ran as root, rare use of jails/chroot, no stack
protection, no NX bit, etc. etc. etc.) that sysadmin time was cheap in
comparison to the gains.  Even small gains were worth spending man hours on.

These days disk are cheap, ram is cheap, security is way better, buffer
overflows are getting rarer, network services are usually setup pretty
reasonably by default.  Sure mounting as noexec can help... unless of course
apparmor or selinux already made a profile dramatically more restrictive
already.  So you could spend time tuning which flags for each of the 8
partitions.... of course you might well make a mistake like Karsten did and
leave exec on for /tmp.  So what use case adds security by using noexec if
/tmp is world readable and mounted with exec?

Using 8 partitions causes more complexity requires more optimization in a
never ending circle.  Oh the humanity...  just imagine how much space you
would save by deleting those unneeded hugely inefficient journals.  Never mind
it's the 8 partitions themselves that creates the need for 7 journals.  Ignore
that various distributions, kernel developers, and the author claim that it
helps availability, data integrity, and speed.  Sure journals are sometimes
slower and they actually take some small amount of disk space.... but if they
save even a single user file that would have been lost with EXT2 that it's
worth it.

IMO the distributions do a pretty good job of the defaults, (like using just a
few partitions) you really shouldn't ignore their defaults without a good
reason.  Sure there are special cases that justify all kinds of weird
configurations.... I wouldn't start with 8 partitions as a default basic
recommendation.  If you are really I/O limited there's many things to tune
before you start looking at partition sizes.

The page also makes a few mentioned of ro, seems a bit silly.  So if only root
can write to /usr, and root can remount rw what are you protection from?
Sure you might prevent a silly user mistake... a tangible benefit..... unless
of course it causes the sysadmin to delay patching because of the extra hoops
of remount instead of the simple apt-get update/upgrade (or clicking on a icon
if you like GUIs).  A single delayed patch might well cost more than you could
ever save with such optimizations 100x over.

Sure things like putting /tmp on a ram disk sounds like a great idea,
especially if you don't really understand the buffer cache.  It should be
really fast right, after all ram is fast... right?  Well as it turns out the
buffer cache works really well on anything that would fit in a ramdisk.
Additionally when you aren't I/O intensive that ram could be useful elsewhere.
 Even if it was 1000x faster I suspect most workloads are not I/O limited by
/tmp anyways.  Not to mention having /tmp survive a reboot might just save you
10 minutes retyping the document you are working on before a power outage.

Would it really be so awful if I could cd /tmp and untar the linux kernel
source tree so I could look at it and then not have to worry about forgetting
to delete it?  With Karsten's recommended config you would start the download
then after waiting realize that /tmp is full.  Sure you could cd ~, then
retry.  Of course then as you get distracted after pouring over the source now
you have 400MB (assuming you didn't build it) wasted in your home directory.

So sure when a partition fills on an 8 partition machine there is less
disruption.... of course you are going to have quite a few more of them.  Not
to mention the effort to get into the 8 partition state... and the effort to
keep all 8 partitions properly balanced.

So basically in a wide variety of uses I think the suggestions on that page
are a silly waste of time that makes a system much more fragile.  The labor
intensive nature basically can't be justified by the small gains offered.  The
gains mentioned are so specific to a use pattern that they appeal to the
engineer/programm/admin that loves to tinker and optimize and on their face
seem plausible.  Two disks can swap twice as fast as one... right?  Well of
course.... except for those nasty real life details.  Say that your system is
*gasp* actually using I/O system at the same time it's generating all the
memory pressure that causes the swapping.  So suddenly those disk head that
would have happily stayed exactly where you wanted it is now disappearing for
1/60th of a second to go load a block for you.   Which of course you could
improve some by juggling the partitions close to the swap next time you have a
day to kill.... unless of you have the moxie to actually do something I/O
intensive on another partition.

Should I really closely watch all 7 partitions?  God forbid apt-get cache to
many packages, I really should go in there and clean up all those packages....
which of course cost me man hours... and again if I end up reinstalling the
ones I just cleaned up.

>> * Crude partition based backups
> 
> You'd rather provide an explicit and laundry list of directories (that
> must then be maintained), when just adding "-x" (don't cross filesystem
> boundaries) to your rsync command solves that problem entirely?  Really?

Er, yes.  Why would I want to tie what I backup to a partition boundary?
Doubly so for a system with 8 partitions.  In Karsten's config do you think
it's a bonus that if you backup /usr/local that /usr/local/data doesn't get
backed up?  If I'm happy to reinstall from DVD/CD/PXE if necessary (after all
a disk death is rare enough I'm likely to want an upgrade anyways) why not let
me backup /etc, /home, and /opt (or /usr/local if you prefer) instead of, er,
/dev/hda2, /dev/sda5, /dev/hda7, and /dev/hda3 (which gets more than /etc).

In any case, by crude partition based backups I meant things like dump restore
vs the current rather elegant solutions that add things like deplication,
support of efficient storage and network usage via librsync, easy to use
configuration system, *gasp* user friendly GUIs, etc.  Not to mention that the
more current file based (not partition based) backup systems allow backing up
to a much wider range of targets.  Sure CD, DVD.. much like the tapes of old,
but also using rsync, or even various network/cloud services like s3 or
rsync.net.  Thus it becomes much easier to get replicated offsite backups cheaply.