Talk:Features/tmp-on-tmpfs

It seems like this wasn't thought through very well. The User Experience section says "The user experience should barely change" however, I've noticed massive breakage after moving to F19. I was unable to restore my F18 Evolution email backup because /tmp is now limited to 2GB, which was far from enough for Evolution to unpack a 10GB backup file. Midnight Commander's handy ability to dynamically browse all types of archive files (gz, bz2, zip, etc) is completely broken because it's constantly running out of disk space on /tmp. It seems even command line operations and scripts that rely on tar/gzip are broken too unless they can be modified to use an alternate tmp directory. For this change of have been made without changing the user experience, you would have needed to change the way dozens of highly used applications work and this wasn't done. Instead everything that used to rely on /tmp being large enough to park arbitrarily large tmp files is completely b0rked.

Now we'll have to go through the usual endless finger-pointing while every application developer refuses to change the way their program works just because Fedora developers broke the /tmp file system and Fedora folks will refuse to fix Fedora because they think all the applications are broken. Eventually, we'll get some compromise like switching all programs to /some/other/path/tmp that will serve the same purpose /tmp used to before it was broken. Was this outcome really not obvious to anyone within the Fedora development community? [end of rant...] Steevithak (talk) 20:02, 9 July 2013 (UTC)

I think implementing this the way you're doing it, where it changes existing setups on upgrade, is a bad idea, because it will leak the disk space used by the original /tmp and the administrator will have no obvious way to get at those files to delete them (even more so if the "administrator" is just an average home user). It's also quite rude to change existing setups that way.

I think this should be set up in the default fstab for new installations only (if at all). (The reason you give for not using fstab is so it also works for upgrades, but that's exactly the wrong thing to do.)

I'm also worried about the compatibility with many existing applications, and I disagree about the Downloads xdg-user-dir being an appropriate place for temporary downloaded files, as opposed to downloads the user intends to keep. But the decision to overrule the existing fstab instead of honoring it is the biggest issue.

--Kkofler 21:03, 31 March 2012 (UTC)

We definitely should update existing setups, how we do it for all other changes too. /tmp is kind of an "API" VFS (i.e. unlikely real device FS like for /home), and APIs shouldn't differ between installations. (By "API" VFS I mean that is there to implement a certain API to application -- in this case mkstemp() and mkdtemp() and friends -- and not to provide user storage). And it's not at all rude to make upgrades to the system if the user explicitly started the upgrade process.

Simply mounting /tmp over is not really "leaking" since this does not actually result in any additional disk usage. We can document in the release notes how the admin/user can reclaim the space used by old /tmp files.

This definitely should not be listed in /etc/fstab, since it is an API VFS and we want to keep those out of the view of the admin/user. It is something that "should just work", in the background, without being visible to the user. It's not something that is supposed to be primary subject to user configuration, and be exposed as a direct configuration option by listing it in fstab.

In fact, we believe that the delta towards stateless read-only systems should be made minimal and we should head towards installing an entirely empty fstab by default, so that fstab is exclusive property by the admin and user.

Also, not changing /tmp to tmpfs by default for existing installtions will mean that our testing base during the development of Fedora 18 will be much smaller and we have no chance finding out which applications are incompatible with tmpfs on tmpfs.

Patching /etc/fstab on package installation is not realistically possible, since it cannot be implemented idempotent (i.e. if we place the /tmp entry in fstab once, and the user removes/comments it, on the next upgrade we'd have to readd it).

Finally, the tmpfs .mount unit is an upstream change that is now available in other distributions, too. We should not deviate in Fedora from that. Not even Debian lists /tmp in fstab anymore.

Compatibility with applications is a real problem, but some nebulous fear of it is is not going to help. The only thing that is going to help is finding out more about it, is by enabling it across a big number of development installations, and collecting feedback. Hence we suggest to enable this early in the development process in F18 and be prepared to revert it.

You know, the answer to "there might be a problem! OMG!" is not "let's not do it", but "ok, let's find a process to figure out if that's really true, and whether we can fix it". And that's what we are doing here. Enable it early in F18, collect data, fix if possible, revert if not. Also, Debian has already turned this on and is collecting information about it in their development cycle. They have already found a small number couple of culprits, which are being fixed.

Uh? no, "temporary" downloaded files should not be in xdg-user-dir's download directory. Did anybody claim that? It's the directory for user downloads and user downloads-in-progress. Please don't spread FUD.

--Lennart 10:28, 2 April 2012 (UTC)

BTW, we now changed things so that /etc/fstab takes precedence over our distro tmp.mount unit. That means the user can change the /tmp fs by editing fstab just fine, and we'll not override what the user might have configured there before with the upgrade.

--Lennart 16:30, 2 April 2012 (UTC)

That doesn't help the common case where /tmp is on / and where your new tmpfs now shadows it. Sure, disk space will not increase, but there will be files totally unreachable during normal operation (which is perfectly in my definition of "leaked"), and unmounting /tmp (to get at those files) is impractical to impossible on a running system, it requires reconfiguration, a reboot, reversion of the reconfiguration and another reboot to perform reliably.

--Kkofler 03:01, 3 April 2012 (UTC)

sudo mount /dev/sda1 /some/where/just/to/see/whats/inside/tmpdir will do the trick.

Peter Lemenkov

Mounting the already mounted partition again? Are you sure that's going to work?

--Kkofler 22:26, 3 April 2012 (UTC)

tmpfs effects on small-memory systems

I am concerned with effects of this change on small memory systems. This may not be a mainline concern at the moment, but in my opinion Fedora should increasingly pay attention to tablet/netbook systems which are projected to grow more important than the traditional desktops, and those are likely to skimp on memory for price and battery life reasons.

With on-disk /tmp, the buffer cache prevents excessive writing if there's memory to spare, but the system still works when memory is used up. What happens with tmpfs? The memory required for the /tmp filesystem is bound to increase swapping for other programs as well as the tmpfs memory itself, which will hammer the disks even more. The lack of quotas on tmpfs makes it hard to control.

Perhaps this should be a default only for systems with ample memory. Could it be a startup-time setting that is flipped back to on-disk /tmp if some sustained memory exhaustion is detected?

Regarding the possible waste of disk due to shadowing of /tmp, I like Simo Sorce's suggestion: 'mv /tmp /tmp.old; mkdir /tmp'

BTW, I thought that the buffer cache makes the "tmpfs is faster" argument mostly moot.

debian concerns

As pointed out on the fedora-devel within Debian there are still concerns about this feature, resulting in a huge mailing list thread about it (yet again). Buried within however are some comments from Joey Hess and Russ Allbery, which to me correctly point out why there is resistance against this proposal: the split might not be good enough. Would it not be better to try to make a good split at once, by separating the promise about longevity of files and the promise of (slow) disk vs (fast) memory? As Russ puts it in his email (but please read the original as he probably makes the point better):

 The root problem here is that we have multiple parameters that we want to
 set on temporary storage:
 1. Space for dumping arbitrary files without assuming anything about the
    structure of the user's home directory.
 2. Fast space for small temporary files that will be removed when the
    system is rebooted.
 3. Space for large temporary files that will be removed when the system is
    rebooted.

Or in other words: what are the plans to separate 1, 2 and 3 and/or are they not related to this feature? Stijn 08:26, 1 June 2012 (UTC)