[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, Apr 13, 2011 at 05:21:18PM +0200, Thomas Hood wrote:
> I just realized that I misunderstood Roger Leigh's posting and so
> my previous message was mostly superfluous.  My apologies.
> 1. His statement "but you have to mount many more to be able to
> break your system" was correct (and can be made more explicit by
> adding "... by filling them all").

Yes, I did word it poorly, I'm afraid.

> 2. His proposal *was* to reduce the size of all tmpfses (together)
> to 50%, as follows:
> /run                     10%
> /run/shm                 20%
> /tmp                     20%
> /run/lock, /lib/init/rw  very small

I should admit that the 50% here is more by coincidence than intent,
but the general idea is that it's restricted overall to a sensible
amount.  Given that tmpfs on /tmp is optional and disabled by default,
it would be 30% + 10MiB for the last two.

What I should have stated more clearly in my earlier messages about
the limits is that we now have the flexibility to choose exactly
how to manage the space.  We can have a single large tmpfs (less
flexible and can be filled up by users, but there's much less
chance of a single part running out of space cf multiple mounts)
or we can have a collection of separate tmpfs mounts with different
size limits (less chance of a user filling a system-only part, but
an increased possibility of a single mount filling up).  Or we can
choose something in between those two extremes.  For the defaults,
I'd like something which will work in all cases, and which can be
easily tweaked for special/non-standard uses.

If we have a single shared tmpfs, 50% core is eminently sensible,
providing you have some swap to back it.  If we have multiple
tmpfs mounts, we do want to consider restricting it further.

The 10% and 20% figures are fairly arbitrary (the 10% comes from the
max. samba usage seen with a big margin added to it; it's still
three orders of magnitude bigger than the average usage of /run).
The 20% is a bit more fuzzy; it's smaller than the 50% default, but
still large enough that the chance of using it all is extremely
remote.  I'm quite happy to adjust these values if needed.

> What remains of my previous message are my two questions:
> 1. Is OOM importantly worse than a full system tmpfs?  I think so
> too, but....

They are both undesirable.  OOM is worse because it's potentially
unrecoverable (the OOM killer can't kill a process to reclaim
space on tmpfs [with the exception of POSIX SHM, but I don't think
the kernel knows about that--it's purely a userspace implementation],
so you can lock up the whole machine).  But equally we don't want to
allow users to interfere with system processes by denying them the
resources they need (e.g. not being able to create a lockfile/pidfile);
but in this situation, it is rather easier to recover since we can
just delete the offending files to free up some space.

[It would be nice if tmpfs offered a superuser-only allocation of
e.g. 5% like ext does, which would go a long way to mitigate
user DoS.]

> 2. Even if so, do we have to worry about OOM happening because
> *multiple* tmpfses got filled?  We are already safe from OOM if
> one tmpfs (whose size is 50% of memory) gets filled.

This is really down to the limits we have set on them.  If we have
sensible limits, even far too large for what we expect to be
typical usage, we're safe from OOM.  With no limit (or more accurately
the default kernel limit), as used at present, adding multiple tmpfs
mounts does make this more likely.  The proposed default values are
intended to satisfy these requirements, but they may well not be
optimal, and I'll be happy to adjust them as needed.


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature

Reply to: