Re: Moving /tmp to tmpfs makes it useless

[Roger Leigh <rleigh@codelibre.net>]

On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote:
> 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.

Nothing in this thread has been ignored.  Please don't make unwarranted
assumptions.  Stating the same thing in 20 different replies doesn't
make it any more useful than stating it in one.  I'm well aware of the
issues involved and haven't "forgotten" anything.

> > 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.

The defaults have been carefully (perhaps even too conservatively)
chosen to prevent any problems with the system becoming unusable.
And you are not correct here.  The tmpfs defaults to guaranteeing
a certain fixed size being available, as I stated above.  If the
memory was used up by applications and data, then the system will
swap, drop cached data, flush unwritten data to disc etc. in order
to make room for it.  You are *guaranteed* to be able to use that
space, and it does not cause problems (modulo the size limit being
too small).  The important point is that the space is absolutely
guranteed to be available, which is something a regular filesystem
does not, unless you dedicate a separate filesystem to /tmp.


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