Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Adam Borowski wrote:
>> Some people asked for a thread summary. So here it is.
> Seriously, can't you even read what's written to you?
Yes, I know it was a biased summary. So as yours. But there's a difference
between mine and yours. Mine is based on some real-world applications,
yours is based on... what? Can you confirm your words with some real-world
use cases, not on artificial tests?
> Sorry for being angry, but there's a limit to how many times you can
> have folks explain the basics of page cache without starting to suspect
> malice.
Then stop explaining theories and show some examples. Theories can be
wrong, examples are not.
You missed some important part of the summary. I skipped almost everything,
that was not related to /tmp or was not confirmed by some popular apps. The
quotes I left were about *real* applications, mysql, gscan2pdf, dvd burning
software, youtube, libreoffice, etc. And since there was no software in the
"upsides" list I have nothing to quote.
> But, for the rest of us, here's a different summary. And note that, even
> though I'm a strong proponent of tmpfs, I say it might be better to skip
> it for wheezy -- so there's a chance this summary is not as biased.
[...]
> And upsides:
> * Massive speed increase for I/O operations:
Really? Well, I can also say that tmpfs is 10000 times slower than ext3.
But if I cannot confirm that on a real-world applications, my words mean
nothing. So as yours.
> * No spin-ups of laptop drives.
Have you ever checked that on real laptops? I did. The *only* case when
/tmp caused additional spinup to me was a flash video. That's all. I
remember no others. Since watching flash video was not the main purpose
of that laptop it wasn't even 1% of total spinups. And it was completly
solved with vm.laptop_mode=1.
Do you want to know what have caused the rest of spinups? The main one was
because of browser accessing the profile. That was about half of all the
spinups. A major part was due to syslog writing to /var/log (by default it
calls fsync on every line, I had to disable that). IIRC, another important
part was because of wtmp being modified every time I open new console (I've
put a hack to disable that too). One more part, not that large but still
noticeable was because of /var/tmp/kdecache, so I reduced it as much as
I could and put it to tmpfs (!). A small part of spinups were because of
something being read from disk, so I hacked readahead so that it put more
files in disk cache.
That's all. /tmp was not even among top10. Why do you think that /tmp has
anything to do with spinups in real world?
> * Less wear of SSD drives.
Again, how many disk writes are related to /tmp? Have you ever checked that?
Can you confirm your words with some numbers or at least some examples?
Do you dismiss the theory (confirmed by Uoti Urpala test script) that
tmpfs+swap INCREASE number of writes and are hence bad for SSD?
> • Contrary to Serge's claims, SSDs are not an oddity, and it's not
> unlikely these will be a majority before wheezy becomes oldstable.
I never said that SSD is an oddity, I said, that putting /tmp on tmpfs
gives you a feeling of false safety. That was based on my own experience.
I `btrace`-d disk usage, I wrote scripts to identify applications doing
most of the writes, and they were not related to /tmp.
Your words look correct in theory, but they're not true in practice.
That's why to avoid theoretical mistakes (any theory can be wrong) I tried
to stick to some popular applications, because they're easy to check and
they can't be wrong.
> This basically boils down to:
> efficiency vs failures for a newbie user.
Yes. Theoretical efficiency vs practical failures.
> So, I'd say:
> * let's play it safe and not default to tmpfs for wheezy
> * do it properly later
There're no real applications benefiting from /tmp on tmpfs now. Nothing
will change later. There maybe fewer failures later, but still zero benefits
to applications on the real world. Either now or later putting /tmp on tmpfs
by default is useless in real world. That's the problem. :)
--
Serge
Reply to: