Just a few comments regarding the current Debian defaults, since I'm mostly responsible for the current use of tmpfs on /tmp.
As mentioned in
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.)
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.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds