On Tue, Apr 12, 2011 at 08:19:59PM +0100, Roger Leigh wrote: > On Tue, Apr 12, 2011 at 07:44:54AM -0700, Steve Langasek wrote: > > If the problem is that multiple tmpfs are mounted and > > each can expand to half-of-RAM, either reduce the number of tmpfses > > presented (as discussed), or limit the *whole* allocation for known mount > > points to half-of-RAM and partition appropriately, or both. > > For this reason, I've adapted the patch to move /dev/shm to /run/shm; > it's configurable whether this is a separate tmpfs mount, or simply > a subdirectory of /run, and the size is also configurable as before > (SHM_SIZE, with RAMSHM as the option to toggle the mounting). We > could additionally allow /tmp to be moved under /run/tmp, so that > all existing tmpfs mounts could share a single tmpfs (I haven't > done this yet). Currently we mount a tmpfs on /tmp if RAMTMP=yes > or root is mounted read-only, but we could move it under /run. I should add here that while the other distributions have moved /var/run and /var/lock under /run, they have not moved /dev/shm or /tmp. I'm not sure what the consensus is on doing either of these, so I haven't put either into the proposed patch yet. I think the question to answer here is whether or not /dev/shm and /tmp offer the same lifetime policies as /var/run and /var/lock, and whether or not they logically fit under the same heirarchy. The first is clearly the case: they can all be on tmpfs. Whether they logically fit is not so clear. I think that if we have /run/lock, /run/shm makes sense (how different are locks and POSIX semaphores? They are just a different type of lock (broadly). And shared memory is ephemeral state, just like samba's state etc.). So I would argue that it does fit. But this isn't a universally held opinion. Is there any rationale against doing this? I'm not as sure about /run/tmp, though all the files under /run are strictly temporary, they are pretty much all system files rather than being owned by users (though /run/lock and /run/shm would be user-writable; however, there are proposals to restrict access to /lock as on Fedora). 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.
Description: Digital signature