On Mon, Jun 18, 2012 at 11:42:06PM +0200, Wouter Verhelst wrote:
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.
Maybe, but we are talking about defaults. Please correct me, but I think that most Debian systems are in some way single user systems.
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.
If you train the user to keep away from /tmp, because it may be too small with tmpfs, how much programs will use it then?
- 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.
I agree, but only if your tmpfs is big enough to hold the file. Ripping DVDs or BDs will exceed any tmpfs limit on most systems.
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).
Nobody disagrees that RAM is faster than disk, but I hope you don’t disagree as well that most people will have more disk space than RAM.
Now whether that advantage outweighs the disadvantages you've outlined is something we can talk about. However, whether RAM is faster than disk
Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk.
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).
But this will only happen if your /tmp is not a separate partition. And it can happen with /var as well. I’ve seen programs logging so fast that /var had no space left breaking the logging and the database.
We can now start another discussion what should be the best partition layout for a default installation, but /tmp is not the only problem. And /var/tmp exists as well for everyone writeable.
Stephan -- | Stephan Seitz E-Mail: stse@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature