2012/5/27 Iustin Pop wrote: > There's a difference between "tmpfs is bad" and "the defaults for tmpfs > are bad".
First, I'm not saying that tmpfs is just bad. It's GOOD. For some cases. I use it myself when I need to be sure that (having enough RAM) some of my *large* files will never leave the cache and will *read* really fast even when not used for days. It's not about "tmpfs is bad". It's about "/tmp on tmpfs is bad". And if "/tmp on tmpfs is bad", it does mean that "defaults for tmpfs are bad", doesn't it? > There are benefits, but your broken benchmarks don't show it. Possible. That's why in almost every email I'm asking for a better test, better usecase, some popular applications, anything, proving it's good. But still... > Your tests are wrong, as Adam Borowski very nicely explained. My "test" was `time tar xf ~/linux-3.4.tar.bz2`. It's not "wrong", it's probably the most real test suggested so far. Aren't you using tar/bzip2? It's a much better test than some artificial bash/perl-scripts that nobody use in real-life. And we're still talking about real-life default settings, I hope. Those bash snippets I wrote were just to check about fsync(). It's stupid to change defaults because some useless bash script works faster. Imagine that I wrote an application that works faster on reiserfs than on ext*fs. Will you change debian *default* root filesystem to reiserfs because of my own application that nobody else uses? The truth is that tmpfs IS FASTER in some cases. The problem is that *nobody* can notice that on *real* applications. So in some artificial world on another planet /tmp on tmpfs could be a good idea, but we're in the real world on Earth, aren't we? >> 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. Ok, honestly, I don't know ANY popular applications, heavily fsync()ing files in /tmp. Can you name some? Otherwise what's the reason to optimize for fsync() if noone uses it for /tmp? > 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 My guess about people using tmpfs is based on the fact that during last few days of this discussion and a few monthes of previous discussions I've read through nobody had finally said why using /tmp on tmpfs is good. Everybody are trying to say why it's "not that bad", but *nobody* explains why it's good. This is the first thread where we're at least trying to do that (first benchmarks appeared). And, by the way, I see nothing bad in people being ignorant. I am ignorant in some things. It's impossible to know everything in the world. That's why I ask others to help me and find out why /tmp on tmpfs is good. Or, if we won't find it, disable it by default. > Honestly, other people in this thread have made the point against tmpfs > much better than you That's because I'm NOT trying to find why /tmp on tmpfs is bad. It's easy and obvious. Instead I'm trying to find why it's a good default. Is it? Why? Is it good just because it's "not that bad"? > I will stop replying to this thread, because I don't have much to add; > there are pros and cons to both solutions Then, can you, please, mail me directly, and name the pros. I'm trying to collect all the points. And I still miss yours. I understand you believe it's not bad for you. Ok. But why /tmp on tmpfs is good for you? -- 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/caoveneqyifbjwv4z1zn7to0x9x+urd6cggaxkvcod6gs-q6...@mail.gmail.com