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
Attachment:
pgpxuw0qCqImY.pgp
Description: PGP signature