Re: Moving /tmp to tmpfs makes it useless
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.)
Regarding space usage on /tmp, I think I mentioned this before, but
I'm not sure it was on-list, so I'll reiterate it here.
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, which is a
guarantee a regular filesystem does not offer (unless you have a
dedicated filesystem for /tmp, which is getting outside the scope
of this discussion).
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.
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?
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.
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.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: