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.
Comments (119 posted)
If you're interested in working on it I can imagine a number of places
to shove this data and I know what's necessary from the rpmdb/yum
history/repos to do it.
-- Seth Vidal
How can 'opening a big .ppt I was just sent', be a corner case? That's
the sort of thing 'normal people' do on a daily basis.
And if we have any pretence of Debian being useful outside the people
on this list we really should have defaults which mean it 'just
works' (if your disk isn't full already).
Comments (3 posted)
The Fedora 17 release is out. "Frankly, we believe this is the beefiest release ever -- chock full of
condiments, more commonly known as Features, to customize your
experience to your tastes. We take pride in our toppings, and in our
fine ingredients; Fedora 17 includes both over- and under-the-bun
improvements that show off the power and flexibility of the advancing
state of free (range) software.
" Details can be found in the
Fedora 17 feature list
Full Story (comments: 24)
A Fedora 17 beta for ARM is now available
. There are a number of images provided
for various targets ("QEMU, Trimslice, Beagleboard XM and iMX based hardware platforms.
") "We invite you to take part in making Fedora 17 for ARM a solid release by downloading, testing,
providing your valuable feedback. Please join us on the IRC in #fedora-arm on Freenode or send
feedback and comments to the ARM mailing list.
Full Story (comments: 3)
Now that Fedora 17 is out, Fedora 15 is approaching its end-of-life. There
will be no more updates for Fedora 15 after June 26.
Full Story (comments: none)
Enrico Zini reports on some changes in the Debian New Maintainer process.
"AM (Application Manager) reports were a bit of a burden of
bureaucracy, and it has been the case that applications got stuck for
considerable time waiting for the AM to have the time to write the report.
Let us fix that: forget about writing the AM reports!
Full Story (comments: none)
The Cooperative Bug Isolation Project (CBI) is now available for Fedora
17. The CBI
research effort designed to find out what went wrong when your application
crashes. "We currently offer instrumented versions of Evolution, The
GIMP, GNOME Panel, Gnumeric, Liferea, Nautilus, Pidgin, and Rhythmbox.
Full Story (comments: none)
Newsletters and articles of interest
Comments (none posted)
Ryan Paul takes
at Unity and the Heads-Up Dispaly (HUD) in the 12.04 release. "The HUD is powered by the same mechanism that supports Unity’s global menu system. In order to make an application’s menus available to Unity so that it can display it in the panel, the contents of the menu are relayed over the D-Bus interprocess communication system. The HUD taps into that data, essentially offering an alternate presentation of the menu. In addition to being extremely useful, the HUD is a compelling illustration of how Unity’s architectural strengths can be put to use in novel ways.
Comments (1 posted)
The H has a nice summary
of the new features in Fedora 17
. "Of the many changes made, the two that stand out are software rendering for GNOME Shell and the sandbox function for isolating applications. These, and many other changes, are likely to find their way into other distributions soon. Time will tell whether that will also be the case for the much-discussed filesystem reorganisation.
Comments (8 posted)
Linux.com has an interview
with SUSE's Vice-President of Engineering Ralf Flaxa. "Linux.com:
What’s the significance of 20 years in business? Ralf Flaxa: The significance comes in our longevity, which even surprises us to a degree. In fact, our first reaction was “Hey, 20 years!” There have been many other distributions that have come and gone – we were one of the first and we’re still here. We view the staying power as very significant.
Comments (2 posted)
Page editor: Rebecca Sobol
Next page: Development>>