Re: Summary: Moving /tmp to tmpfs makes it useless
On Wed, Jun 20, 2012 at 03:18:55PM +0200, Stephan Seitz wrote:
> 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.
Not in my experience.
> >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?
This argument is circular.
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?
> >- 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.
Not necessarily. Ffmpeg's two-pass video encoding uses a temporary file
to which it writes statistics about the video file being processed
(mainly data about how fast the image moves, etc), which it can then use
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.
The _output_ of the encoder (the encoded MPEG file) in the first pass is
irrelevant, and can in fact be thrown away. That's the whole point of
doing two-pass encoding.
So that leaves you with reading a whole lot of data from disk, and
writing a temporary file to RAM.
> >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.
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.
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.
> >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.
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.
> >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.
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).
> 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.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: