Re: how to increase space for tmpfs /tmp
On Tue, Mar 27, 2012 at 02:58:52PM +0000, Camaleón wrote:
> On Tue, 27 Mar 2012 14:13:23 +0100, Roger Leigh wrote:
> > As the person who created these defaults, just a few points for everyone
> > in this thread to consider:
>
> > A common (and very persuasive) argument for not mounting a tmpfs on /tmp
> > and instead using the root filesystem is that by default we install with
> > a single large root filesystem, and /tmp gets to use all the free space
> > there. This is certainly true, and is a major reason why we should
> > consider doing this.
>
> I also share that feeling.
>
> > However, the following points also need to be considered:
> >
> > - having /tmp on / means that / needs to be writable by default
> > - having "limitless" space on /tmp means it can be abused by
> > both users and applications. It can lead to breakage on systems with
> > a limited /tmp if applications make the (incorrect) assumption that
> > they can store whatever they like there. It's more sensible to
> > provide a minimum guarantee.
> > - /var/tmp exists, and should be used in many of the cases where
> > /tmp is being filled.
> >
> > It's hard to get a clear picture of what generally useful defaults
> > should be when you only get feedback from a handful of users.
>
> IMO, the rule of thumb for applying a new default is asking ourselves if
> the new default will cause any problem to the users. If yes, then don't
> touch the old default and keep it the way it was. If we are not going to
> get any improvement but just for the 10% of our user-base, then we are
> failing the 90% of the rest.
I can understand that running out of space is annoying and
frustrating. That's not the intent of the changes by any means.
Defaulting to putting /tmp on the rootfs solves this /particular/
problem simply. Assuming that your rootfs has sufficient amounts
of free space. That's by no means a given. Some root filesystems
are small. Others are full. Some are NFS mounted and have very
poor performance for temporary files. The point is that there are
no guarantees. On some systems, /tmp on the rootfs will be far
worse than on tmpfs.
However, while this would solve the immediate problem, it does
create other less immediate but still important ones. Application
written with the assumption that they can create huge temporary files
will work well on these "fixed" systems, but will be broken by
default on smaller systems. The issues being reported are by and
large a symptom of that. In most of these cases, the best long-term
outcome would be for those applications to be fixed. Not to do so
would cause more long-term pain as a result of an easy short-term
fix.
It's for reasons such as this that I think use of /tmp should
come with certain requirements. Size is one issue. Lifetime is
another. The borderline between what is "temporary" and what is
just user data is not always clear. I've used Solaris systems in
the past which had a total /tmp size of just a few tens of
megabytes, and an enforced lifetime of just 60 minutes. That was
annoying, but it ensured that it was only used for *genuinely*
temporary data of limited size. Obviously that's far too extreme,
but there are extremes in the other direction, and I think quite a
few applications are abusing /tmp badly.
Applications should not be selfish, and should not blindly fill it.
Take the streaming media example from earlier today. Is it
appropriate to dump potentially limitless streams of data to /tmp?
/Obviously/, it's going to be filled to capacity at some point; any
application not coping with this /inevitability/ is broken.
If it's being streamed, isn't buffering sufficient? Otherwise, it
might as well be termed "downloading". And in the example of /tmp
being filled by big downloads, is /tmp the appropriate place for
that, either? I would personally say no. That's not its purpose.
Once I have internet at home and I can work on sysvinit again (I
just moved house and started a new job), I will certainly be looking
at this more closely. Initially this will be looking at improving
the tmpfs defaults, but we can certainly look at not making it the
default.
Note that sysvinit has both a git repo and a mailing list. Bug
reports (there are several on this issue) can be commented on, and
patches provided where appropriate and/or possible.
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: