On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote:
Maybe, but we are talking about defaults. Please correct me, but I think that most Debian systems are in some way single user systems.Not in my experience.
So most of your Debian systems have several users working at the same time on the same system? Okay, then you have a different user base.
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?This argument is circular.
I beg to disagree.
If you train the user to keep away from /tmp, because it may be too slow without tmpfs, how many programs will use it then?
But the disk will not be so slow to break applications like they would if you run out of disk space. So we weight a time advantage against an enough space advantage. And since the user don’t know about tmpfs they won’t think that there /tmp is slow.
Besides disk /tmp is still faster than NFS /home. ;-)
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.Not necessarily. Ffmpeg's two-pass video encoding uses a temporary file to which it writes statistics about the video file being processed
Ah, thank you for the explanation, but
to optimize the encoder in the second pass. This statistics file contains data such as "at time index X, Y% of the image changes" in ASCII form, and hence need not be much larger than some tens of megabytes for a full-sized DVD.
if the file is only about some tens of megabytes, do you really gain so much speed?
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.That leads us to the crux of the discussion: we are both right. You are right in that /tmp on disk lowers the chance of /tmp running out of space, which is a real problem. I, and others arguing in favour of tmpfs, are right that placing /tmp on tmpfs will speed up things and (if not using any swap space) will reduce usage of an SSD, both of which are real improvements.
I still think that the SSD problem is not a valid concern as long as we don’t have solutions for /var and log daemons. There is more traffic in /var than in /tmp.
If we really want to optimize for SSDs we should do something like: - /tmp and /var/tmp on tmpfs - no local logging or the possibility to enter a log server- patching any applications like iceweasel to store their cache on a tmpfs
- running trim daemon for discard (maybe)This could be part of an enhanced laptop mode because it would safe battery time for normal disks as well.
The question is: what matters most? To me, the performance improvements of tmpfs are significant enough to warrant making it the default. Clearly, you disagree.
Yes, because the performance improvements will only get you speed but risk breakage of the application because /tmp is now smaller than it was before tmpfs times. On the other hand disk /tmp will make some things slower, but in the end it is safer. And I think users understand the problem of a full disk much easier than how to expand a full ram 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.While I think a compromise would be wonderful, I don't think this is it. Additionally, I don't think this is technically and aesthetically a very good solution.
Well, why? Other suggestions were to write daemons monitoring tmpfs and increasing it if necessary together with swap space. Or writing a daemon to blend tmpfs and disk together. Besides that these daemons must be written and tested first it sounds much to complicated to me. With my suggestion you have both worlds available without manual configuration by the user, and we can encourage our users to test it and report to us if they find it useful or not. I see the advantages of tmpfs but I wouldn’t replace my disk tmp with it, only have it as alternative.
But this will only happen if your /tmp is not a separate partition.Yes; but if you're going to make /tmp be a separate partition, then your argument that there's more space on disk doesn't really hold anymore, either, since now /tmp is much much smaller than your disk (I've never seen a system with a separate partition for /tmp use more than a few gigs for that partition).
While you are right that /tmp on a separate partition is smaller than the disk, you are wrong (at least in my cases) that tmpfs would now be bigger than disk /tmp. My smallest disk is 250GB, my biggest 2TB, still all my systems have only 4GB RAM. At my company there are some systems with 8GB RAM, some even with 16GB (eclipse user), but the disks are at least 500GB.
/tmp has always been about 10-20GB big, because I expect users to store big temporary images in /tmp. I won’t get this with tmpfs and I would have to train the users to change their behaviour.
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.Absolutely, I'm not contesting that (in fact, I've recently had a very similar situation at a customer). But this discussion is not about /var, it's about /tmp.
Yes, it is, but if tmpfs is seen as an advantage because /tmp can’t block the system anymore and prevent DOS attacks (among others), this doesn’t sound so good anymore if you can as easily block the system by filling /var/tmp or /var/log.
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