[HEADS-UP] Rawhide: /tmp is now on tmpfs

[Brian Wheeler]

On 06/01/2012 12:21 PM, Lennart Poettering wrote:
> I think most of the noise in this flame thread is due to a
> misunderstanding how modern memory management works and the assumption
> that having an explicit size limit on /tmp was a bad thing, even though
> it actually is a good thing... In fact, we need much stronger limits
> than what tmpfs currently provides: per-user limits on the usage of
> /tmp. But that's something for the future...
>
> Lennart
>

I understand how memory management works...which is why this seems like 
a terrible idea.

Can you provide numbers that show that there is a speed increase with 
this scheme which offsets the amount of change required to do this?  I 
haven't seen anything other than "its faster".

This is change is troublesome for multiple reasons:
* It switches the semantics of what /tmp is.  Its now apparently for 
small and short-lived files.  Where small and
short-lived are defined based on the RAM usage at the time a file is 
created.  Hooray for heisenbugs!
* everything that did use /tmp now should use /var/tmp which means 
patching a ton of programs and hoping that third party applications do 
the same thing.  So the "problem" this fixes with /tmp now exists in 
/var/tmp.
* there are no numbers which back up the purported benefits
* file data gets moved out of RAM (in this case, to swap) not when it is 
convenient for the kernel at a potentially idle time but when the kernel 
is experiencing memory pressure.
* changing the amount of space available in /tmp means screwing with 
swap files

How is this change a win?