Quoting Erik Christiansen (dvalin@???):

> That leaves /var, which I've kept separate for three decades, to obviate
> the risk of furious rates of logging fatally depleting /. OK, it takes
> longer now, but the principle remains.

Tip (and one man's opinion):

On servers, I've long found it useful to hsve /var as an ext2 filesystem
(for highest raw performance), with the following mount options:
noatime,nodev,nosuid

The noatime option further and substantially reduces metadata overhead,
another non-trivial boost to system disk performance. The other two
are an aid against software mishap and a first-level obstacle against
automated system-cracking tools -- there being no legitimate reason for
device nodes or SUID binaries on that filesystem. (Depending on your
system, you probably want to ensure that /var/lib and /var/spool are
served from elsewhere, either separate filesystems of their own or
symlinks to trees elsewhere /like to dirs under /home or some such.)

> Growth of /tmp was never a problem, as removal of several day old tmp
> files was/is a standard cronjob, at least after you've been bitten once.

I actually think tmpfs for /tmp is a fine idea, provided (1) you are
aware of what'll happen if it balloons, and (2) you're OK with it being
backed by volatile storage and aren't surprised by it being empty after
reboots including unplanned ones. The speed gain is serious.

If nervous about all of /tmp being volatile, you could, e.g., have
subdir /var/volatile only mounted as tmpfs.

For me, I'm leaning towards all of /tmp being on tmpfs and _no_ swap of
any kind on near-future server systems because of intended use of only
SSDs, no spinning rust at all. I don't have hard data, but suspect that
the wear on SSDs from swap activity is substantial to a degree that
outweighs swap's functional utility -- for my use-case, at least. I
intend to have a go at a style of operation where running out of
physical RAM means the OOM killer gets loose for a while, and see how
that goes. The implicity assumption is 'I'll try to avoid that by
having enough RAM and not running tasks configured so they're likely to
blow up and drive the system into swap.' My metrics say that I haven't
been driving into swap, so it's probably a reasonable stance.
.