Talk:Features/tmp-on-tmpfs

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)