Re: how to increase space for tmpfs /tmp
On Tue, 27 Mar 2012 14:13:23 +0100, Roger Leigh wrote:
> 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:
(...)
>> > 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:
Ahem! So it were you... okay, okay... let me a minute so I can sharpen my
sword >:-) (just kidding).
> 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.
That's understandable but maybe asking to the Debian community for
feedback would have been a good idea to see what other users think about
this, what problems they experience with the chosen default or providing
additional improvements. I (as a user) already did it so by asking here
and knowing about other's experience.
> 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
> --------
Which is the source of many of the user's problems and complaints.
> 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.
I've had no problems at all with "/run" and "/run/lock" and still keep
them using the default settings (tmpfs). With "/tmp" is another story.
(...)
> 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.
I already gave my POV on this. Having a "tmpfs" for "/tmp" can be a good
default as long as it accomodates the space properly. That is, I will
never give 100 MiB to /tmp, that's simply crazy for a system with 250 GiB
of hard disk space as any simple operating that uses /tmp will crash at
the middle of the run.
> 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.
> 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.
First questions that need to be asked (in this order) would be:
- Should we need to set tmpfs as default for /tmp?
- If yes, what could be the default size? Going to the limits or keep it
small and handy?
> 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.
Every user will find his/her way to manage this. But unless I get any
compelling reason to enable it again, it will be off by (my) default.
> 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.
Being configurable from the installer is a great idea provided it can be
also disabled from here. Anyway, most of the users will just keep the
default settings because they will doubt about what's the best for their
systems (keep tmpfs on/off, tpmfs size...).
> [There are prior discussions of this on -devel, which probably include
> more detail and other things I unintentionally omitted.]
Yes, I already was pointed to that thread and read it in detail. And
thanks for taking the time to write such a detailed explanation and share
your thoughts on this.
Greetings,
--
Camaleón
Reply to: