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 -- 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/20120527132036.ga19...@teal.hq.k1024.org