Why I hate having /tmp as a tmpfs

April 5, 2012

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.)

Written on 05 April 2012.
« More on equality in Python (well, mostly Python 2.7)
Why we haven't taken to DTrace »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Apr 5 01:09:48 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.