Re: Summary: Moving /tmp to tmpfs makes it useless
On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote:
> 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.
"webserver".
Additionally, in $DAYJOB I do indeed maintain a number of systems where
users log in remotely (through VNC and/or NX) and work on the system,
with several people logged in at the same time.
[...]
> >>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?
Yes.
Filesystems and disks are very good at optimizing sequential reads from
a single (large) file if no other disk access happens at the same time.
However, if you write to another file during that sequential access, you
take a performance hit, since now there's more than just one file.
It's not about the size of the file as opposed to about having
additional disk access interfering with optimizations.
Having said that, this is besides the point, really. The point is that
yes, tmpfs is really faster. I gave you a few examples where this is
true, but the examples aren't really the point; the fact that tmpfs is
indeed faster, is. You can maybe convince me that in one or two specific
use cases it won't matter much, but not that it won't matter as a whole.
RAM is faster than disk. That's a fact. Therefore, tmpfs will be faster
than disk, too, and that's an advantage.
Can we stop talking about specific use cases now?
> >>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.
You're letting the perfect be the enemy of the good, then.
Yes, /var produces changes to storage, too, but that doesn't mean we
shouldn't optimize /tmp because we can't optimize /var. That makes no
sense.
> 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)
I'm not saying we should "optimize for SSDs". I'm just saying that
storing on tmpfs is beneficial for SSDs.
I'm not trying to steer the discussion towards SSDs or anything; I just
think that tmpfs is a good option for /tmp, for various reasons. That we
can get the same effects with other measures is great, but of no
relevance for a discussion about tmpfs.
[...]
> >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?
Because it would end up being a directory that nearly nobody would use
directly. Those who want to use a ramdisk will just remove that
directory (or make it a symlink) and mount /tmp on tmpfs instead, and
those who don't want to use it will probably just ignore it.
Also, if deciding on a reasonable default for /tmp is difficult, think
about deciding on a reasonable default for individual packages. That's
going to be even harder.
Meanwhile, you've got a non-FHS directory on your system that is of no
immediate use.
> 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.
Wasn't my suggestion, and I agree with you (also, those "solutions"
wouldn't be much cleaner, either)
[...]
> >>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.
I believe this is part of our disagreement: I don't think system-wide
directories are meant for users to use directly. In other words, I don't
think users should put large downloads in /tmp; instead, they should put
such files in a subdirectory of their homedirectory -- and if you really
need some scratch space, using some other directory (the systems I
referred to above have fairly large partitions mounted under "/store")
would seem to be preferential.
> >>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.
I don't agree with that argument.
True, the simple fact that the impact of filling up /tmp is reduced
doesn't mean there's no other way anymore to fill up the hard disk. But
that doesn't mean there's suddenly no benefit anymore in avoiding that
pitfall.
And the fact that you can fill up /var and break the system should not
be an argument to allow people to also fill up /tmp and break the
system, "because you can't solve that problem anyway". Sure, you can't,
but that doesn't mean it's not worth it.
If this were a security measure, you might have a point; there's no
reason in filling one security hole but leaving another one wide open.
But this is not about security, it's about common system usage.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: