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. Regards, Roger -- .''`. 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.
signature.asc
Description: Digital signature
