2012-04-05
Why I hate having /tmp as a tmpfs
There is a recent move in Linux to turn /tmp
into a tmpfs. As a sysadmin, I am afraid that I have a visceral dislike
of this (and always have).
The core problem with a RAM-backed /tmp is that it creates a new easy
way to accidentally DOS your machine. When /tmp is only a disk, it's
pretty clear how much space you have left and filling up /tmp is only
a minor to moderate inconvenience. When /tmp is backed by RAM, filling
up /tmp means driving your machine out of memory (something that Linux
generally has an explosive reaction to). Worse, how much /tmp space
you really have is unpredictable because it depends on how much RAM
you need for other things. In theory this might be predictable, but in
practice RAM demands are subject to abrupt and rapid swings as programs
start and stop and change what they're doing.
(Even without a bad reaction from the Linux kernel to an OOM, an OOM
situation is both worse and more wide-ranging than having /tmp or even
the root filesystem run out of space. Being out of memory affects pretty
much everything on the machine, and that's assuming you don't have enough
swap space to cause your machine to melt down.)
This is bad enough on a single-user machine, where at least you are
only blowing your own foot off when you DOS the machine through an
accidental OOM because you (through old habits) or your program
(through not being revised to the latest nominal standards) innocently put something
sufficiently large in /tmp. On shared multi-user machines, it's pretty
close to intolerable; the damage done is much larger and so is the
chances of it happening, since all you need is one person to have one
accident.
(By the way, this is not theoretical. We have had people put
multi-gigabyte temporary files in /tmp, especially on our compute
servers. Sometimes they manage to fill /tmp up, even though it has
many gigabytes of disk space.)
Ultimately, what making /tmp into a tmpfs does in practice is
to make the machine more fragile. How much more fragile depends on
what happens on the machine, but it's undeniably more fragile. I
don't like things that make my machines more fragile, so I don't
like this.
By the way I'm aware that other systems (such as Solaris) did this years
ago. I didn't like this transition on them either, for exactly this
reason. I consider it a really good thing that only staff can log on to
our Solaris machines, because a RAM-backed /tmp makes them too fragile
for me to be happy with general access to Solaris.
(See also SysAdmin1138.)
Sidebar: the right way to do this transition
It's really simple: make a new /tmpfs mount point
that is, well a tmpfs. The latest new standards make it clear that any
number of programs need revising anyways to put their data in the right
place; while you are revising those programs, you can perfectly well
make them use /tmpfs when appropriate. And the result does not blow
people's feet off when they continue following decades of user behavior
and program defaults. If you want and it makes you feel better, you can
then make /tmp into a symlink to /var/tmp.
(As usual, this is certain Linux people not solving the real problem.)