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.
But still...
> 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,
I hope.
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
> hardware
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?
--
Serge
Reply to: