Temporary files on Linux have traditionally been written to /tmp,
at least those that don't need to persist across boots. Several Linux
distributions are now planning to mount /tmp as a RAM-based tmpfs
which should generally be an improvement in a wide variety of
scenarios—but not all. Debian
has been planning to make that switch for the upcoming "wheezy" (7.0)
release, but as a discussion on debian-devel shows, not all are happy with
Mounting /tmp on tmpfs puts all of the temporary files in RAM.
That will reduce the amount of disk I/O that needs to be done, as the
filesystem never actually touches the disk unless there is memory
pressure. In that case, the tmpfs memory could get swapped out like other
pages in the system, but in many cases a temporary file will be created without needing any disk I/O. The installer (or system
administrator) can specify a maximum size for the filesystem as part of the
mount options, but the
memory is only actually used if files are written to it.
The latest incarnation of the dispute over putting /tmp into RAM
(vs. having it as a disk directory in / or its own partition) was
started by a posting from "Serge" that claimed the change was
"useless". His complaint stemmed from various applications
that put large files into /tmp (long videos, ISO images, unpacked
archives, sort temporary files, etc.), which can cause problems for
systems with little memory or
with too small of a tmpfs. He argued that putting /tmp on tmpfs
by default was the wrong choice for new users, and that savvy users could
make the switch (or know enough to choose it at install time).
It is clear that there is a difference of opinion among participants in the
thread about how /tmp
should be used. Several people thought that /var/tmp should be
used for large temporary files, with /tmp reserved for small
files. Others pointed out that the file hierarchy standard (FHS) just says
that /tmp is for files that do not need to persist across reboots,
while /var/tmp is for those that do. But using /var/tmp
for non-persistent large files has a drawback: those files do not get
cleaned up on boot, unlike /tmp files—at least on Debian.
Many thread posters have been running their systems with a
RAM-based /tmp for a long time with few or no issues, while
others are clearly running into problems in that configuration. Large
videos downloaded via the Flash plugin seem to be a particular problem, but
there are others. It really comes down to a question of what /tmp
Many in the long thread—something of a Debian tradition—believe
that writing large files to /tmp is the wrong thing for an
application to do. But no real alternative location that preserves the "wipe on
reboot" semantics for /tmp has been offered. Workarounds like
the TMPDIR environment variable can be used, but whatever
directory that points to may just fill up with garbage over time.
Running out of /tmp space is a problem regardless of what kind of
filesystem lies under it, but in the default Debian installation a
disk-based /tmp will essentially have the whole disk available, as
it only creates a single / partition.
On the other hand, a RAM-based /tmp will almost certainly be much
smaller, which can lead to applications filling up the filesystem much
more easily. Even if those applications are "wrong" to do so, they
evidently exist, so forcing users to confront that problem at times
could be sub-optimal. More advanced users can make their own choice.
There were numerous invocations of Solaris in the thread as well, because
it has used a RAM-based temporary filesystem for many years, seemingly
without many problems. Russ Allbery said
that he started in the "Solaris has been doing this for
years, what's the problem?" camp, but after reading some of the
objections in the thread had basically changed his mind. It comes down to
a question of functionality vs. speed. For a default setting, working should be
preferred over speed optimization.
As Joey Hess pointed out, until there are
clear numbers about the performance improvement that comes from a RAM-based
/tmp, making it the default is a premature optimization. There
were examples offered where tmpfs made an enormous performance difference,
but the question is not whether the feature is useful; it is, instead,
whether it should be the default.
This is not the first time the issue has come up. Roger Leigh posted pointers to other threads and bug
reports (some of which have their own long threads, of course). He is the
developer that added the tmpfs-based /tmp for wheezy, but he
mostly stayed clear of the discussion this time. It does not look like he is
inclined to remove the default, though, so there have been suggestions that
the issue be referred to the technical committee.
It is interesting to note that Fedora plans to move to a RAM-based
/tmp for Fedora 18, and has already enabled it for Rawhide. The Fedora feature
page notes that Solaris has been doing so since 1994 and that Arch
currently defaults to a tmpfs-based /tmp. It also mentions that
Debian and Ubuntu both plan to move in that direction.
At least for the near future—and probably beyond—RAM sizes will
generally be far less than those of disks, particularly for machines
targeted at non-technical users. While those users might benefit from the
performance improvements that come from keeping /tmp in RAM, there
is a risk that their applications will chew up their RAM with huge
temporary files, leading to swap storms or broken applications.
The Solaris example may not be all that compelling as it is not
really a consumer-oriented desktop system. The other Linux distributions
may offer a better test case and Debian may
well get the benefit of seeing what happens with them
before wheezy is completely frozen. On the other hand, though, it is not
really clear that Debian targets (or attracts) many novice users, so why
make the vast majority of Debian users suffer the penalty of disk-based
/tmp when they don't really need to? They can certainly switch
to that, but the default might serve the majority quite well. At this
point, one suspects
that RAM-based /tmp will soon be the norm and that applications
"fixed", but only time will tell.
to post comments)