Re: Moving /tmp to tmpfs makes it useless
On 05/28/2012 05:32 AM, Roger Leigh wrote:
> On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
>> On 05/25/2012 07:44 PM, Roger Leigh wrote:
>>> However, the majority of
>>> software which finds the tmpfs too small has unreasonable expectations
>>> of what can be expected to be available (by default).
>>>
>> We welcome you to rewrite / patch these software then!
>> Good luck, the list is huge, and growing every day this
>> thread is alive.
>
> (As an aside, could you possibly reduce the number of mails you're
> sending. You've sent at least 12 today, and most of them all
> said essentially the same thing.)
I'll do that when people will stop ignoring arguments posted on the very
first message of the thread, like the fact so many popular applications
are writing big files to /tmp, and that it's simply unrealistic to
believe we can fix them all before Wheezy. You seem to forget it once
more in this post as well.
> The primary cause of problems is simply that the tmpfs /tmp isn't
> big enough. Applications are creating files which use up all the
> space. I'd like us to consider the problem in terms of what
> guarantees are offered by the system in terms of minimum and
> maximum available space on /tmp. Consider the default: /tmp is
> on the rootfs, and there is a single filesystem (which might be
> very large or quite small, and may have lots of free space or
> very little). In this case, we offer no guarantees about the
> available space. Now in the typical case, we might well have
> tens, or even hundreds, of GiB available, which can be used by
> files under /tmp. But this is not guaranteed. There might be
> next to no free space. Now consider tmpfs mounted on /tmp: the
> size specifies the total available space. This is guaranteed to
> be available; it's both the minimum and maximum, so while it /might/
> place a lower upper limit on size than a regular filesystem would,
> it also guarantees that this space will be available
Unless I didn't understand how tmpfs work, you have no guarantee as
well. Once your memory is eaten by apps, and your swap gets full, you
are in the exact same situation as having your /tmp holding partition
full, at the exception that your system becomes totally unusable and
unstable.
> If the default size of the tmpfs is too small, we should decide
> what is a reasonable size, and ensure that the installer makes
> sure sufficient swap is available by default, or disables tmpfs
> on /tmp if this is not possible.
There's simply no such thing. You can't decide arbitrarily how big the
.ppt files the user will import, what kind of MySQL dbs in use, or how
big the archives opened by mc will be.
> My other comment is regarding software having reasonable
> expectations about the space they can use and, just as importantly,
> how they cope when those expectations are not met.
>
> In the example of streaming video using all the space on /tmp, the
> space used is approxiately proportional to the length of the video
> stream being downloaded. Looked at another way, the file is of
> completely arbitrary size, and the application should be able to deal
> with running out of space--resources are not finite, and failure should
> be expected given the indeterminism implicit in the downloading. Is
> /tmp even appropriate for this use?
As you wrote, nothing is infinite. I don't think that /tmp is worse than
/home like other said. Your /home could become full as well.
> Another example was not having enough space when processing images.
> As mentioned by Neil Williams, it's important to tailor the
> software and hardware to requirements, and others mentioned issues
> with what happens when the tmpfs starts swapping. You obviously
> don't want to swap unless you absolutely have to. I process multi-GiB
> images using 8GiB RAM, 16GiB swap and a 6GiB tmpfs on /tmp. They get
> copied to /tmp, have multiple operations performed on the temporary
> copy, and get written back out. The performance is great--it's always
> working on in-memory data, with a single copy to/from a regular
> filesystem. But this was not a default configuration--it was
> deliberately configured for the job. This will always be needed to get
> optimal performance, whether you use a tmpfs or not. The system was
> tailored to meet the expectations of the image processing software.
Unfortunately, we aren't talking about having /tmp using tmpfs by
default if there's more than X GB of RAM. This is an unconditional
default that we're talking about here. If it was let's say using tmpfs
if there's more than 4GB of RAM, I don't think there would be so many
people complaining that this might be a bad choice.
> The best size for /tmp is of course the size which lets you store all
> your data without it getting full. However, when its size is
> essentially unlimited, there's a danger here. Software can assume
> that it can fill it without restriction, and not need to deal with
> space restrictions. While this isn't a problem on a desktop with
> vast amounts of disc space, it does mean the software is essentially
> imposing this requirement on *all* systems, including resource-
> constrained systems, or else it's basically broken. This is not a
> new problem--it's been an issue with mc as long as I remember. But
> that does not make it desirable.
Right. We never wished to be in the current situation. Nobody denies it.
But it's the way it is, and we have to deal with it.
Thomas
Reply to: