On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote: > On Mon, Apr 11, 2011 at 08:01:42PM +0100, Roger Leigh wrote: > > With the transition to /run and /run/lock as tmpfs filesystems, it > > would be desirable to provide sensible default size limits. Currently, > > we default to the tmpfs default of ½ RAM. But with several tmpfs > > filesystems, this does have the potential for the system to be OOMed > > by a user filling up more than one of the filesystems. A sensible > > default size limit would be useful here, for at least some of the > > filesystems.
> > We currently allow specification of size limits for: > > /run (RUN_SIZE) > > /run/lock (LOCK_SIZE, optional) > > /dev/shm (SHM_SIZE) > > /tmp (TMP_SIZE, optional) > > [from temporary git repo at > > http://git.debian.org/?p=collab-maint/sysvinit;a=summary] > > In order to default to a sensible size, I would appreciate it if I > > could have some figures for the useage of these filesystems: e.g. > > % sudo du -sk /var/run /var/lock /dev/shm > /var/run: Most systems use just 1-200 KiB. A few use a lot (tens of > MiB). The large users appear to be Samba, which creates a number of > .tdb files under /var/run in addition to pidfiles; presumably on > very busy systems, these can grow to be quite large. I guess they > are transient state, but is /var/run the appropriate place for them? Yes, it is, per the FHS. > If so, we need to take this into account. > One system had a > 1MiB /var/run/samba/namelist.debug file, which > could possibly have been put elsewhere. It fits the FHS definition for /var/run. It doesn't belong elsewhere. > wins.tdb, connections.tdb and locking.tdb in particular look like they > can potentially grow very large; would keeping these on /var and deleting > them on server restart be more appropriate than using /run? utmp could > also potentially grow to several MiB. Keep them *where* on /var? They're already exactly where the FHS says they should be. The server will null them out on startup, which is precisely the sort of file that's *meant to be stored in /var/run*. > Without taking Samba into consideration, 10MiB would be more than > plenty for all but the most extreme uses. Allowing for Samba, we need > at least 30MiB, and potentially >50MiB for a good safety margin. Any > comments from the Samba maintainers? I would like to know what real-world problem you're trying to solve by limiting the size of these filesystems. Have you had actual reports of users running into trouble with the current half-of-RAM default filling up? I've never heard such a thing. This is a root-only filesystem, so if the user has a service that wants that much space for temp files, why impose additional limits? 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. But imposing stricter limits than necessary based on survey data is just wrong. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110412144454.gc9...@virgil.dodds.net