On Wed, Jun 13, 2012 at 04:14:52AM +0300, Serge wrote: > 2012/6/10 Wouter Verhelst wrote: > > >> A lot of people (including you) said that tmpfs makes things faster. But > >> there were no examples of popular use-cases becoming faster because > >> of /tmp on tmpfs, so I had nothing to quote. > > > > You're not even trying. > > > > if tmpfs is faster than (say) ext4, then anything which uses /tmp will > > obviously speed up. > > That's not true. Only applications, that are limited by /tmp speed will > become faster then. Do you know such applications?
Any application which performs I/O anywhere has a chance of being limited by it. If you write to /tmp on disk and someone or something calls "sync" at precisely the wrong moment, you're stuck, and your performance suffers. Not so with tmpfs. I'm not saying the speedup will be extreme, but it will be there, and (cumulated over loads of programs using /tmp) it will be significant enough to be noticeable. > > Can I provide a use case where this will matter? Not necessarily. But > > then, can you provide a use case where this will *not* matter? Really? > > Yes. Everything. Oh, interesting. You have the data to back that claim up? > Every popular /tmp usage that most users expect to work > is limited either by CPU (gcc compiling) I don't think compiling C code has been CPU bound since before I was born (and I was born in the late 70s, so that's quite a while). C++ is a different matter, but still. > or by network speed (browser or flash temporaries), or is just too > fast already (bash heredoc). You make it sound as if those three are the only uses of /tmp. That's just not true. Here are some other real-world uses of /tmp, which are (or can be) I/O bound and where the size is significant enough that it makes a difference: - The nbd test suite stores fairly large files in $TMPDIR on which it then runs nbd-server (yes, maybe that's cheating since I maintain nbd; still, it's been that way for quite some time now, certainly since before tmpfs was the default). - Any data transformation or filtering which needs to be done in multiple passes over a file would use a temporary file for intermediate results, which it then reads in again for the next pass. Multi-pass video transcoding is an example of this, and which (depending on the codecs used and the hardware on which it runs) could certainly be I/O bound. - using mc on a tar.gz which was compressed with --fast I could probably go on if I really wanted to, but that's fairly boring. The point is that neither you nor I can reasonably be expected to list all possible uses of /tmp; and that RAM is faster than disk, so that when you access a tmpfs you're going to be somewhat faster than when you access a disk-backed filesystem, at least until you start swapping (if not longer). Now whether that advantage outweighs the disadvantages you've outlined is something we can talk about. However, whether RAM is faster than disk isn't; and the fact that avoiding disk access will result in speedups, no matter how small, isn't up for discussion either. [...] > >> Nobody could provide examples or numbers of how much /tmp on tmpfs > >> reduces amount of writes, and tests showed that tmpfs+swap may even > >> increase amount of writes (hence not always good for SSD), > > > > True, but then swapping to an SSD is the "best" idea since "640kB is > > enough for everyone" :-) > > Hm, it's a bad idea to use tmpfs with swap... And it's not a good idea > to use tmpfs without swap, since it would be too small and may even > trigger OOM killer. When is it good to use tmpfs then? ;) I never used tmpfs on a system with swap, and I've not often seen the OOM killer start doing its job. My current machine has 4GiB of RAM, which seems to be more than enough. The only exception was when I was trying to run one VM too many, which then tried to eat up 110% of my RAM, but that wasn't a good idea in any case. [...] > >> tmpfs does not have 5% overflow safety, > > > > Because it doesn't need it. > > The 5% overflow safety exists for two reasons: > > - to avoid excessive fragmentation (which is not relevant for tmpfs) > > - to allow you to clean up when the filesystem does fill up. > > You missed one more reason. When user fills the entire /tmp on disk, it > does not break system services, since root can still use those 5%. Most system services do not run as root, so that's not a real advantage. However, even if they did, your statement is still wrong: > User cannot break the system filling /tmp on disk. But he can do that > if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of > failure for servers. No, that's not true. The real danger in filling up /tmp is not that other processes can't write temporary files anymore (causing a minority of processes to hang or die; those who just happen to need temporary storage at that point in time), but that no process can write any file anymore (causing a significant majority of processes to hang or die). -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120618214206.gy25...@grep.be
