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:
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
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
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.
Gismo / Luca