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

[Harald Hoyer]

On Thu, Jul 12, 2012 at 6:43 PM, David Sommerseth <davids at redhat.com> wrote:
> -----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?).
>

Again.. tmpfs is restricted to half the RAM size by default. You can't
store 8-9GB of trash.. only 2GB, which might land on swap over time.