* Luca Capello <l...@pca.it> [110414 06:43]:
> 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.
>
> 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
Luca,
It appears to me that you understand perfectly what RAMLOCK does. Your
issue appears to be with the wording of the man page. To me (as a
native English speaker) the wording is explicit about what will happen
if you set RAMLOCK=yes (i.e. a tmpfs will be allocated and mounted at
/var/lock--soon to be /run/lock), but is ambiguous as to what will
happen if RAMLOCK=no. The implicit meaning is that no tmpfs will be
allocated _for /var/lock_ and it will be on the same file system as
/var, whatever that may be (soon to be /run/lock and /run). So the
implicit behavior is that if RAMLOCK=no, and /var is a tmpfs, /var/lock
will simply be a part of the tmpfs on /var. This is indeed the current
(pre-/run) behavior, and is exactly the same as what will soon be with
/run.
The current wording of the man page seems correct to me, even for the
new /run directory structure (with appropriate changes from /var/lock to
/run/lock), but some minor changes in wording would make the RAMLOCK=no
behavior more explicit. I would add the word "separate" and a sentence
describing the behavior when RAMLOCK=no:
Make /var/lock/ available as a separate ram file system (tmpfs).
Will also disable cleaning of /var/lock/ during boot. Set to 'yes'
to enable, to 'no' to disable. When 'no', /var/lock is on the same
file system as /var. The size of the tmpfs can be controlled using
TMPFS_SIZE and LOCK_SIZE in /etc/default/tmpfs. Because of this,
packages can not expect directories in /var/lock to exist after
boot. Packages expecting this are buggy and need to be fixed.
If you like this wording, you should file a wishlist bug on the
initscripts package. (I'm not going to because the current wording
doesn't bother me.)
...Marvin
--
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/20110414132723.ga3...@cleo.wdw
