tmpfs for /tmp

[Martin Pitt]

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 think early quantal would be a great time to enable this, so that we
have some time to identify problematic programs.

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

What do others think?

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20120505/657e951c/attachment.pgp>