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

[Lennart Poettering]

On Fri, 01.06.12 16:19, Richard W.M. Jones (rjones at redhat.com) wrote:

> On Fri, Jun 01, 2012 at 11:05:26AM -0400, Gregory Maxwell wrote:
> > On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno <greno at verizon.net> wrote:
> > > So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls
> > > for everything else they do.
> > > That's crazy.
> > 
> > Thats not true (and I've used tmpfs for tmp for years, so I'm speaking
> > from experience)— tmpfs is backed by swap on demand. Just add the
> > space that you would have used for /tmp to your swap.
> 
> The *default* limit for tmpfs is half of physical RAM (swap is not
> counted).  So *if* tmp-on-tmpfs is left at the defaults then
> increasing physical RAM might be necessary.  I haven't bothered to
> look at how tmp-on-tmpfs is implemented in systemd though.

I think most folks here really misunderstand what tmpfs is. It's not
actually strictly RAM that is used for it, it's *pageable* memory after
all. tmpfs is basically RAM preferred, and swap it if we are under
pressure. ext3 otoh means must be on disk in the end, but cache in RAM
as much as you want. The difference here is hence not really whether
things go to disk eventually or not, or whether this takes away precious
RAM, because both use disk and both can use RAM. The difference is that
the kernel is relieved from the requirement to guarantee integrity on
disk, and to write everything to disk ultimately at all if it doesn't
otherwise need to. And that's what makes things a bit faster, and
reduces general IO load and wakeups.

Beyond that it's also kind of nice that this way stuff from /tmp is
allocated from a different pool as the rest of the OS so that we can
easily apply different limits, but that's just a nice side benefit.

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

-- 
Lennart Poettering - Red Hat, Inc.