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