Re: how to increase space for tmpfs /tmp
On Sun, Mar 25, 2012 at 10:51:07AM +0000, Camaleón wrote:
> On Sat, 24 Mar 2012 12:40:12 -0600, Javier Vasquez wrote:
> > On Sat, Mar 24, 2012 at 11:10 AM, Camaleón <noelamac@gmail.com> wrote:
> >>>> You may also consider filing a bug, since the more people report
> >>>> problems with Debian's new, absurdly small /tmp, the more likely it
> >>>> is to get fixed.
> >> +5
> >>> Why?
> >> Because the default is giving some headaches to the users?
> > How many? Or how many would you consider critical mass to make things
> > change?
> > To me it's just not possible to provide defaults satisfying all users.
>
> Of course.
>
> But when something that was working stops doing it my auto-defense system
> sends me a warn (beep, beep!) and I have to find what have caused the
> problem. When a default setting is causing the problem then the default
> is not good for me. When other users complain for the same issue, then
> the default is neither good for they and it can be a signal for that
> default is reviewed and commented with other community of users to get
> more feedback.
As the person who created these defaults, just a few points for
everyone in this thread to consider:
The existing defaults are not intended to be universally usable.
They are intended to work on every system to provide a certain
base level of functionality. That being said, improvements are
always welcome. The defaults are intended to work on even
systems without swap, so are intentionally small:
/run RUN_SIZE 10%
/run/lock LOCK_SIZE 5MiB
/run/shm SHM_SIZE[=TMPFS_SIZE] 20%
/tmp TMP_SIZE[=TMPFS_SIZE] 20%
--------
50%+5MiB
--------
The intention here is that if every tmpfs is filled, you only commit
50% of core memory. Of course, if you have lots of swap space, you
can increase these limits massively. Or you can disable the use of
tmpfs (except for /run) and use normal filesystems. The run and lock
sizes are I think appropriate for all but the most extreme uses.
shm and tmp are very dependent upon specific application use, and
choosing sensible defaults here is hard.
Regarding altering of the size limits: currently hardcoded in
/lib/init/tmpfs.sh. We could compute these dynamically if we
know at the time how much swap is additionally available. Or
have different profiles depending upon expected usage.
Regarding the use of /tmp on tmpfs being the default. I still
think that tmpfs makes sense for /tmp. It is certainly appropriate
for many users. We can certainly improve the defaults if we
understand what problems users are having. But they need to be
reported.
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. 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.
What should the minimum space be for /tmp?
What is the minimum space an individual user or application should
be able to use?
Should certain applications be patched not to use /tmp for
storing "excessively large" files?
etc.
These are obviously not questions with straightforward answers.
But I hope they do help to provide some understanding as to why
simply not using tmpfs on /tmp is not necessarily the "right" or
best long-term strategy. This definitely needs more thought, but
it also needs a greater understanding of what users and applications
expect /tmp to provide.
Investigating what other init systems and distributions do might be
instructive here.
When we introduced these defaults, we wanted to make them configurable
directly in the installer, by making tmpfs mounts editable in the
partitioner (or removed entirely). I'd still like to do this, but it
needs someone with the time to add tmpfs filesystem support to d-i. I
took a look a few months back, but lacked the time or d-i expertise to
do this.
[There are prior discussions of this on -devel, which probably
include more detail and other things I unintentionally omitted.]
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: