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

[David Sommerseth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/12 19:42, Brian Wheeler wrote:
> 
> 
> 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?

I sense a long term strategy ...

a) Move /tmp to tmpfs
b) all programs using /tmp uses /var/tmp
c) all failing programs enforces $TMPDIR to be set to /var/tmp
d) Somebody discovers that /tmp is no longer in use - and propose to
   remove /tmp all in all

But we're just at the beginning...

Having that said ... I really see some benefits of /tmp on tmpfs, but
for large workloads which depends on /tmp or $TMPDIR it will be a
pain, no matter what, IMO.  And it strikes me as interesting that
Solaris have been doing a similar tmpfs approach for years; yet still
the thumb-rule seems to be "get rid of that ram-fs-stuff and put /tmp
on a real drive".  And I wonder why........

A couple of times (several years ago now), I've experienced /tmp being
filled up with junk - and at that time /tmp was a part of /.  And that
caused even more fun challenges.  So I started deploying /tmp on a
separate LVM logical volume, with a restricted space.  Since that
time, all systems have been running quite stable - despite /tmp
getting filled up from time to time. But that's usually not a problem,
as in worst case that misbehaving program just dies.

But I'm really curious to see what happens if this happens on a tmpfs
based /tmp.  If you have 4GB RAM server and a 4GB swap ... and then a
program hits the system creating 8-9GB of trash in /tmp ... how will
that impact the performance and responsiveness of the overall system?
 How will applications reading data from these memory pages being
swapped out behave (in a performance, point of view)  Will OOM killer
at some point kick in?  And if OOM killer starts, I'm curious which
processes it will pick to kill ... I imagine this to be particular
funny if you're running something RAM intensive, like something Java
based (JBoss anyone?).

I've been seeing a tendency for quite some that these new "features"
in Fedora only benefits a smaller restricted set of laptop (and to
some degree workstation) configurations ... while Fedora is the base
for something far bigger and real servers might have completely
different needs.  But as they say ... ignorance is a bliss ...

Yes, /tmp on tmpfs might make a lot of sense on many
laptops/netbooks/ultrabooks, SSD based systems and other places where
I/O load and energy consumption is crucial - and especially if you
have plenty of RAM.  But (spinning) disk space is still fairly cheap,
and /tmp on a real disk behaves in a predictable manner - even with
misbehaving programs.  And RAM is far more expensive per GB than
spinning disks.

I'm sorry to say, I still haven't really seen any good arguments why
this move is a clever idea on *all* installations.  Some
installations, yes, but default for not all.


kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/+/qkACgkQIIWEatLf4HfORQCfT2fkdb0150xoFYNP6w4h8Bve
LPMAn38F/0IJERoTy759UfykGWc406lv
=+v6l
-----END PGP SIGNATURE-----