Re: Moving /tmp to tmpfs makes it useless
On Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh wrote:
> On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
> > I've read across different debates about whether using tmpfs is good or bad
> > but I could not find the most important reason, so here it is...
>
> I haven't got anything particularly new to add to the discussion here.
[This was also posted to LWN in part.]
As mentioned in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674517 it was
originally intended that this feature only be enabled for new
installs, not on upgrade. As mentioned in this bug, some of that has
been rectified already in git. We will also correct the configuration
for users who got tmpfs enabled during upgrade, but this needs careful
testing. The main issue for it being enabled on upgrades is that
insufficient swap may be available to have a reasonable amount of
space. This is also an issue for new installs--we do need some support
in the installer for this as well.
I'm certainly not averse to switching the default back, if this is the
best solution at the present time for the majority of our users. As
was seen in both this an earlier discussions, there is not a clear-cut
consensus here--there are from what I can tell approximately equal
numbers in the "for" and "against" camps. It's clear we can't satisfy
everyone no matter which is picked as the default.
As mentioned, the use of tmpfs really boils down to peoples
expectations of what /tmp is /for/. The size of what may be stored
isn't specified in any standard, so it's not fair to say that it's
only usable for "small" files. But using a tmpfs does place a
restriction of the size of the files which may be used. That said,
allowing certain applications to store multi-GiB files on /tmp causes
its own indirect problems in addition to the immediate: these programs
are often broken on smaller systems due to not being able to cope with
running out of space, and impose a requirement for vast amounts of
temporary space. These programs are broken on systems with a smaller
rootfs, irrespective of the tmpfs issue.
Maybe we need to distinguish not on size, but on speed of access, and
have /tmp for "fast" access and a separate location for slower
disc-backed storage, which would be more suited to the storage of
streaming media, ISO images etc. which are going to have a longer
lifetime, and also tend to be larger. None of these uses benefit from
being on a tmpfs in the general case. (I've used /scratch for this in
the past, though currently it's a 1 TiB btrfs RAID1 under
/srv/scratch.) Obviously out of scope for wheezy.
The important part of what we've achieved for wheezy is having tmpfs
filesystems mounted on /run (and optionally /run/lock and /run/shm).
The tmpfs on /tmp uses the same infrastructure in our init scripts,
and we mount tmpfs on /tmp in two special cases: if the rootfs is
read-only and no /tmp mount exists in fstab, and if /tmp contains less
than a certain amount of free space. This is one part of making it
possible to run with a read-only rootfs out of the box, and also to
aid recovery if booting when the rootfs is full, respectively.
The default of whether we mount tmpfs on /tmp by default or not is
really only a minor part of the other improvements we have in
wheezy--it really doesn't matter which is the default, so long as it
works. While I'm in favour of this being tmpfs, if there are too many
programs which break which can't be fixed, then we'll have to switch
back to using a regular filesystem. Maybe we'll then be able to
reconsider it for wheezy+1.
[As an ironic aside, when testing RAMTMP=no in rcS for backward
compatibility for #674517, I ran out of space on /tmp and broke
gcc/ld. On my system, there's only a few hundreds of MiB free on
the rootfs; tmpfs is absolutely needed here!]
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: