[HEADS-UP] Rawhide: /tmp is now on tmpfs
bdwheele at indiana.edu
Fri Jun 1 17:42:15 UTC 2012
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...
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
* 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
How is this change a win?
More information about the devel