Action required: Rawhide: /tmp is now on tmpfs
simo at redhat.com
Fri Jun 1 17:02:05 UTC 2012
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?
> 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.
> > 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.
> 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
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
Simo Sorce * Red Hat, Inc * New York
More information about the devel