Action required: Rawhide: /tmp is now on tmpfs

[Simo Sorce]

On Fri, 2012-06-01 at 12:18 -0400, DJ Delorie wrote:
> I'm going to chime in once to add my thoughts...  It's already way too
> late for me to influence the decision (first I heard of it is "it's
> decided") so my only recourse is to add it to the long list of things
> I have to "undo" after installing Fedora.
> 
> > Sorry guys, this feature sucks.
> 
> +1 on this feature sucks.  Perhaps not for the same reasons.  It's
> mostly for this one:

The more I think of it the more I tend to +1 as well.

> > And how is a random user supposed to know this?

They won't

[..]

> These choices are being made without "empowering the users" at all,
> since the changes happen without warning them, advising them, or
> letting them choose beforehand.  IMHO this is the wrong way to do it.

I am not sure asking is the right thing, I think tmpfs in RAM should be
an *optional* supporte dfeature for those users that have a workload
that *will* benefit from this feature and therefore *will* seek it.

By all means make it easy to enable it in some config file or even GUI,
but setting it up by default seem to be misguided.

> My system is already maxxed out on RAM, I can't buy any more, and
> *yes* I need that RAM to be process RAM:
> 
>              total       used       free     shared    buffers     cached
> Mem:      24739484   19815180    4924304          0    4600752    1428024
> -/+ buffers/cache:   13786404   10953080
> Swap:      2056312     816072    1240240
> 
> > With /tmp in RAM, it's not flushed at _boot_, but at _shutdown_
> 
> Losing /tmp on system crashes makes it harder to diagnose them, if
> there's information in /tmp relevent to the crash.  There have been
> *lots* of time I've gone digging through /tmp looking for some interim
> file that turned out to be not so temporary.

Indeed.

> > Just add the space that you would have used for /tmp to your swap.
> 
> My /tmp (/) is 1.2TB (It will be 3TB after this weekend's upgrade).
> It's unrealistic to add that much swap.  Yes, I've had times when I
> need lots of /tmp space, and I don't want to flush my I/O buffers or
> running programs to get it.  I/O buffers are more important to me than
> /tmp speed.

Same here.

> Has anyone even compared the performance of tmpfs-on-swap vs
> tmp-on-ext?  I'm contemplating *removing* my swap because the system
> slows to a crawl anytime swap is needed.  If tmp is on swap, how is
> process performance affected?

I do occasionally run swapoff -a
I do that when I *know* the system is trashing just because the kernel
is caching a lot of crap and swapping out a working set that *do* fit
completely in memory if it weren't for the stupidly overly aggressive
buffer caches.

Having more than a few Gig of swap, esp on rotatory media is just
suicide, and forcing to use swap for /tmp files seem to be really the
wrong way to go *as a default*

> > The *default* limit for tmpfs is half of physical RAM
> 
> I.e. the default limit on tmpfs is to make half your RAM unavailable
> to programs and buffers.  Given how bloated software is becoming
> (Fedora is no exception), this is a step backwards.

On my 'normal' systems once the desktop is fully started with Firfox,
Gnome, Evolution and all the crap, I already am using more than half the
RAM available, so tmpfs in RAM means I hit swap as soon as something
decides to write a tmp file as if we didn't have enough I/O issues with
latest kernels in Fedora, isn't that awesome ? Not!

> In conclusion, /tmp on tmpfs is a non-starter for me, and will be
> changed on my systems as soon as possible.

The risk here is that people will try to build on the fact /tmp is tmpfs
by default, already Lennart hinted tmpfs has nice side effects from his
pov, how soon before /tmp on real disk will cause some features not to
work ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York