Re: Moving /tmp to tmpfs is fine
2012/5/27 Iustin Pop wrote:
> There's a difference between "tmpfs is bad" and "the defaults for tmpfs
> are bad".
First, I'm not saying that tmpfs is just bad. It's GOOD. For some cases.
I use it myself when I need to be sure that (having enough RAM) some of
my *large* files will never leave the cache and will *read* really fast even
when not used for days. It's not about "tmpfs is bad". It's about "/tmp on
tmpfs is bad". And if "/tmp on tmpfs is bad", it does mean that "defaults
for tmpfs are bad", doesn't it?
> There are benefits, but your broken benchmarks don't show it.
Possible. That's why in almost every email I'm asking for a better test,
better usecase, some popular applications, anything, proving it's good.
> Your tests are wrong, as Adam Borowski very nicely explained.
My "test" was `time tar xf ~/linux-3.4.tar.bz2`. It's not "wrong", it's
probably the most real test suggested so far. Aren't you using tar/bzip2?
It's a much better test than some artificial bash/perl-scripts that nobody
use in real-life. And we're still talking about real-life default settings,
Those bash snippets I wrote were just to check about fsync(). It's stupid
to change defaults because some useless bash script works faster.
Imagine that I wrote an application that works faster on reiserfs than
on ext*fs. Will you change debian *default* root filesystem to reiserfs
because of my own application that nobody else uses?
The truth is that tmpfs IS FASTER in some cases. The problem is that
*nobody* can notice that on *real* applications. So in some artificial
world on another planet /tmp on tmpfs could be a good idea, but we're
in the real world on Earth, aren't we?
>> I don't dismiss them. But we talk about *defaults*. And I don't know
>> any real applications, heavily fsync()ing files in /tmp, that people
>> are expected to use by default. Can you name some?
> Which people? You can't overgeneralise.
Ok, honestly, I don't know ANY popular applications, heavily fsync()ing
files in /tmp. Can you name some? Otherwise what's the reason to optimize
for fsync() if noone uses it for /tmp?
> But I don't appreciate the fact that, in your overzealous attitude, you:
> - come up with faulty benchmarks, which show that you misunderstand what
> the bottlenecks are
> - make assumptions that people are using tmpfs because they are ignorant
> - claim that people are using tmpfs only because they have overpowered
My guess about people using tmpfs is based on the fact that during last
few days of this discussion and a few monthes of previous discussions
I've read through nobody had finally said why using /tmp on tmpfs is good.
Everybody are trying to say why it's "not that bad", but *nobody* explains
why it's good. This is the first thread where we're at least trying to do
that (first benchmarks appeared).
And, by the way, I see nothing bad in people being ignorant. I am ignorant
in some things. It's impossible to know everything in the world. That's
why I ask others to help me and find out why /tmp on tmpfs is good. Or,
if we won't find it, disable it by default.
> Honestly, other people in this thread have made the point against tmpfs
> much better than you
That's because I'm NOT trying to find why /tmp on tmpfs is bad. It's easy
and obvious. Instead I'm trying to find why it's a good default. Is it?
Why? Is it good just because it's "not that bad"?
> I will stop replying to this thread, because I don't have much to add;
> there are pros and cons to both solutions
Then, can you, please, mail me directly, and name the pros. I'm trying to
collect all the points. And I still miss yours. I understand you believe
it's not bad for you. Ok. But why /tmp on tmpfs is good for you?