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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caoveneqacnt9wrfdocm-qtde2mnfgo0qzqrj-1_5bab8pzm...@mail.gmail.com
