Hi there! Disclaimer: this is my last post on this matter (i.e. the meaning of RAMLOCK), it seems there is a problem with myself or my understanding.
On Tue, 12 Apr 2011 23:42:58 +0200, Roger Leigh wrote: > On Tue, Apr 12, 2011 at 10:35:37PM +0200, Luca Capello wrote: >> 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: >> >> Currently, `man rcS` gives: >> >> >> >> RAMLOCK >> >> Make /var/lock/ available as a ram file system (tmpfs). [...] >> 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. Either I do not read `man rcS` as you read it or we do not understand each other, so here the situation before and after your patch for /run (/var/lock became useless, everything is in /run/lock now, but I kept using /var/lock for consistency with the previous state): [before] RAMLOCK=no -> /var/lock on the same filesystem /var is on RAMLOCK=yes -> /var/lock on tmpfs [after] RAMLOCK=no -> /var/lock is on tmpfs, shared with /run (given that /var/lock is symlinked/bind-mounted to /run/lock) RAMLOCK=yes -> /var/lock gets its own tmpfs, differently from the one mounted at /run So, the meaning of RAMLOCK, WRT `man rcS` and as I read it, *has* changed. This is where we do not agree on wordings, but given that English is not my mother language, maybe it is only my fault. Thx, bye, Gismo / Luca
pgpinr9sbLCVE.pgp
Description: PGP signature