Re: how to increase space for tmpfs /tmp

[Vincent Lefevre <vincent@vinc17.net>]

On 2012-03-27 14:13:23 +0100, Roger Leigh wrote:
> 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.

What do you mean by "abused"? If it is limitless, there should be
no possible abuse.

IMHO, to avoid breakage due to limited space and due to some user
taking all the space, there should be some compromise, such as:
for any memory storage system (RAM+swap, tmpfs, disk...), there
should be some space normally not used, and reserved for root (and
possibly special system users/groups[*]) in case the normal space
gets filled. AFAIK, this is already the case for disk space.

[*] or arbitrary users, who could have their own reserved space to
be able to do minimal work when some other user took all the space
(i.e. a common pool that has the precedence + quotas on extra pools,
which would be much smaller).

> - /var/tmp exists, and should be used in many of the cases where
>   /tmp is being filled.

But what is applications do not know in advance what to use, given
the fact that the RAM+swap is much more limited than disk space in
practice? Should there be a new FS to transparently use tmpfs for
small files and disk space (/var/tmp or similar) for large files,
and being able to move files from tmpfs to disk space when a file
increases (without changing the pathname)?

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

I have scripts that build and test software, and rm -rf everything
after the tests and/or "make install". So, I was using /tmp for that
(because it is faster than normal disk space, and cleaned-up at boot
time in case something is left over). For small software, it is OK,
but for large ones, /tmp got full. Should I use /var/tmp, even though
/tmp would be OK in most cases? IMHO, the best solution would be some
"union" FS as suggested above.

> What is the minimum space an individual user or application should
> be able to use?

IMHO, the default limit should be the full space minus some small
space to avoid breakage. This is more flexible than strict quotas.

> Should certain applications be patched not to use /tmp for
> storing "excessively large" files?

The problem is that /tmp would be OK for some users and not for
other users, in particular if the applications don't know in
advance the amount of data they will need to store temporarily.

If the answer is "in doubt, do not use /tmp" (possibly affecting
most applications), then this would probably mean that /tmp should
not use tmpfs.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)