On Thu, 29 Mar 2012, Claudio Freire wrote:
On Thu, Mar 29, 2012 at 12:21 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Well, I disagree :-) what you are essentially proposing is not adopting this scheme due to the existent of corner cases and buggy software, not good enough for me.
My point of decreased performance is not a corner case, it can be measured. If tmpfs is used, I'd recommend it be capped at below 10% of total system RAM and, in that case, it would probably swap under pressure and seriously decrease system performance.
But...
This is what I believe must be done:
- For system daemons, turn on PrivateTmp in systemd .services when applicable (list of packages --> https://bugzilla.redhat.com/show_bug.cgi?id=782466) This ensures that temp files are only available to the daemon process and if it crashes or misbehaves files will be deleted on spot.
I totally agree.
- For users, implement what Lnussel and fcrozat suggested, a separate tmp per user in /run/<user>/ tmpfs. Otherwise temporary file creation bugs will keep biting us forever.
And here too, in principle, but there are numerous issues to account for here, including firefox's tendency to put downloads in tmp-dir. If FF picks up this /run/<user> location, we're basically in the same situation as putting /tmp on tmpfs.
- Fix buggy software if any.
Can't argue against that.
Still nobody had a suggestion where to put large short-living data. Like GCC wants to do. Currently it uses TMPDIR, if that ends up being tmpfs it won't work (and no, out-of-disk-space situations are _not_ easy to handle, these are temporary files that are shared across processes). So, what's the location one should use instead (or rather, try first)? From GCCs documentation: @item TMPDIR @findex TMPDIR If @env{TMPDIR} is set, it specifies the directory to use for temporary files. GCC uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper. Richard.