Distributions

Temporary files: RAM or disk?

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 by default, 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 that decision.

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 is for.

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 will get "fixed", but only time will tell.

Comments (119 posted)

Distribution quotes of the week

-- Seth Vidal

-- Wookey

Comments (3 posted)

Fedora 17 released

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)

Fedora 17 ARM Beta Release

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, and 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)

Fedora 15 end of life

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)

bits from the NM process: advocacy, no more AM reports, AMs needed

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)

Cooperative Bug Isolation for Fedora 17

The Cooperative Bug Isolation Project (CBI) is now available for Fedora 17. The CBI is a 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)

Distribution newsletters

• Debian Project News (May 28)
• DistroWatch Weekly, Issue 458 (May 28)
• Maemo Weekly News (May 28)
• Ubuntu Weekly Newsletter (May 27)

Comments (none posted)

Precision and purpose: Ubuntu 12.04 and the Unity HUD reviewed (ars technica)

Ryan Paul takes a look 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)

What's new in Fedora 17 (The H)

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)

SUSE Turns 20, Ascends to the Cloud (Linux.com)

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)