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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120527213208.gu22...@codelibre.net