On Tue, Apr 12, 2011 at 10:35:37PM +0200, Luca Capello wrote: > Hi there! > > On Tue, 12 Apr 2011 20:47:35 +0200, Roger Leigh wrote: > > On Tue, Apr 12, 2011 at 08:12:21PM +0200, Luca Capello wrote: > >> On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote: > >> > Josh Triplett suggested that we could use a single tmpfs on /run and > >> > have the rest as symlinks into /run, with potentially a separate > >> > tmpfs for user-writable filesystems to prevent a user DoS. This idea > >> > does have merit, and we could make it the default. We currently do > >> > this for /var/lock (/run/lock), which can be mounted as a separate > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > tmpfs on /run/lock if RAMLOCK is set in /etc/defaults/rcS. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> Do you mean that the meaning of RAMLOCK has completely changed? > >> Currently, `man rcS` gives: > >> > >> RAMLOCK > >> Make /var/lock/ available as a ram file system (tmpfs). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [...] > >> I consider completely changing it a serious bug, may I suggest > >> deprecating it completely and adding a new variable instead? I guess > >> the same should be applied to RAMRUN, i.e. simply deprecate it. > > > > With the patch as it stands at present, RAMRUN is deprecated. /run > > is always a tmpfs; RUN_SIZE will set its size, as before. > > Fair enough and, FWIW, fully agree. > > > RAMLOCK is unchanged, except for the fact that it's mounted on > > /run/lock rather than /var/lock. > > No, /var/lock changed *substantially*, given that it is now *by default* > (on) a tmpfs, regardless if RAMLOCK is set or not. Which means that > RAMLOCK as it was explained is useless, thus my question about your > words underlined above: "which can be mounted as a separate tmpfs on > /run/lock if RAMLOCK is set in /etc/defaults/rcS". > > I do not have any idea which variable could be straightforward, > something like LOCK_OWN_TMPFS... > > > Likewise, LOCK_SIZE is unchanged in its meaning. > > Again, I found it changed: how can you define LOCK_SIZE if /run/lock is > on the same tmpfs than /run? If you set RAMLOCK=yes, then /run/lock is a *separate* tmpfs of size LOCK_SIZE, *exactly* like the /var/lock tmpfs mount (it's the same code with s/var/run/g). So the actual behaviour of this option is entirely unchanged bar the switch from /var/lock to /run/lock. So by default, /run and /run/lock are on the same tmpfs. But if you set RAMLOCK=yes, you'll get a second tmpfs mounted on /run/lock. So yes, /run/lock will always be on a tmpfs filesystem, that's obviously the main point of the patch. But the sysadmin can configure the size of /run/lock separately should they choose to do so (especially since it's user-writable by default). 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.
Attachment:
signature.asc
Description: Digital signature