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. Otherwise, if this feature causes problems to some applications and no benefits to others, what's the point in using 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. > 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? > 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. 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"... That's just my guess, of course. -- 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/caoveneom+nfemjxs61xqekbbt0ui5_epw0yl9t930ratvhe...@mail.gmail.com
