Re: Moving /tmp to tmpfs is fine
On Sun, May 27, 2012 at 05:39:21AM +0300, Serge wrote:
> 2012/5/25 Iustin Pop wrote:
>
> > And no, "I really can't think of any popular application" is not a valid
> > discussion point.
>
> But there're already popular applications and usecases that break because
> of that. It can render the system unstable because of heavy swap usage.
> So there must be some strong point to still use it despite those problems.
> There must be some very popular application, that do not break because
> of that feature and even becomes better.
There's a difference between "tmpfs is bad" and "the defaults for tmpfs
are bad".
> Otherwise, if this feature causes problems to some applications and no
> benefits to others, what's the point in using it?
There are benefits, but your broken benchmarks don't show it.
> > This is plain wrong. NO benefits for tmpfs? "just works somehow"?
>
> Ok, I must be missing some obvious benefit. Please, help me and name it.
> But real one not theoretical. Some real (and popular, since we're talking
> about defaults) application that becomes faster (or better in any other
> way) because of /tmp being on tmpfs. All the tests showed tmpfs being no
> better than ext3 so far.
Your tests are wrong, as Adam Borowski very nicely explained.
> > you only look at _your_ use case and dismiss all others, or that you
> > don't understand the different behaviours of fsync() (with enough memory,
> > that is) on tmpfs, HDDs and SSDs.
>
> 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.
I agree that the default sizes of tmpfs are likely wrong. But that
doesn't mean, as you claim, that tmpfs itself is wrong.
> > iustin, happily using /tmp on tmpfs since many, many years ago
>
> Heh... A lot of people use it. I guess most of them have seen "/tmp", then
> they were seing "tmpfs", and decided that "tmpfs is the fs for /tmp", it
> seemed natural to them. They never really thought, whether it's good or
> bad idea, or that there may be some better ideas. It was just natural to
> use it.
I appreciate this attack. It helps your point very much to paint people
who argue for tmpfs as clueless people.
> And when I say, "hey, that's a bad idea", I hurt them (I'm sorry for that).
> They start arguing that "it's not that bad as you say, look, not everything
> is broken, many programs still work". They can't say why it's better than
> using disk because they never though about that. It was just "natural"...
Serge, I very much appreciate the fact that you're trying to make a
better experience for Debian users.
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
- etc.
Honestly, other people in this thread have made the point against tmpfs
much better than you; I would suggest you tone down a bit your position,
and stop assuming ignorance on other's people part.
I will stop replying to this thread, because I don't have much to add;
there are pros and cons to both solutions, but I personally I'm still
surprised that people don't see the advantage of tmpfs for not
underpowered memory cases.
regards,
iustin
Reply to: