tmpfs for /tmp

Matt Zimmerman mdz at
Sun May 6 16:22:43 UTC 2012

On Sat, May 05, 2012 at 01:03:13PM -0700, Martin Pitt wrote:
> Hello Phillip,
> Phillip Susi [2012-01-13 15:39 -0500]:
> > Bug #18661 has been requesting that /tmp be mounted as a tmpfs since
> > 2005.  Either this should finally be done, or marked as wontfix.  I
> > would like the TB to decide if this should be done or not.  If not,
> > please mark the bug as wontfix with the rationale, if yes, then it
> > should be as simple as changing the default fstab file in the mountall
> > package from fs type none to tmpfs for /tmp.
> Now that precise is out of the door, I think we should revisit this
> question. A tmpfs /tmp/ is much more efficient for the bulk of stuff
> that goes to /tmp than a real hard disk file system, as it avoids
> disk wakeups, unnecessary IO, etc.
> The regression potential with that change is that there are programs
> which assume that they have plenty of space in /tmp; e. g. Firefox
> downloads things there, unless you use "Save as..". There might also
> be CD burning programs, video encoders etc. which try to place huge
> files there.  So we need to identify those and fix them to put large
> stuff into /var/tmp/ instead.
> In practice it doesn't seem to be so bad, though. I've been running
> with a tmpfs /tmp for quite some months now without problems, but then
> again my computer usage habits are fairly regular and presumably much
> different from the average user (e. g. I don't do video editing or
> CD/DVD burning at all).

I use a tmpfs /tmp on all of my systems, and have for several years without
a problem.  I use Chromium, which downloads things into $HOME, and I haven't
encountered any problems with encoders and the like.

> I think early quantal would be a great time to enable this, so that we
> have some time to identify problematic programs.

I agree.

Another thing to consider is how large it should be, i.e. whether the
default (1/2 RAM?) is suitable.

> I heard that Fedora plans to enable this as well, so there's some
> potential for collaboration and sharing results, too.


 - mdz

More information about the technical-board mailing list