On Thu, Apr 14, 2011 at 09:27:23AM -0400, Marvin Renich wrote: > * Luca Capello <luca@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.) New text, which is hopefully clear enough: RAMLOCK Make /run/lock/ available as a ram file system (tmpfs). Set to 'yes' to enable, to 'no' to disable (defaults to yes). The size of the tmpfs can be controlled using TMPFS_SIZE and LOCK_SIZE in /etc/default/tmpfs. Note that irrespective of this setting /run/lock will be located on a tmpfs, either one mounted on /run/lock (if RAMLOCK=yes) or one mounted on /run (if RAM‐ LOCK=no), and as a result the contents of /var/lock will always be lost on system reboot, and it it is no longer explicitly cleaned at boot. Because of this, packages can not expect directories in /var/lock to exist after boot. Packages expect‐ ing this are buggy and need to be fixed. Note that /run/lock was previously /var/lock, and a compatibility symlink or bind mount will be created to allow the old path to continue to func‐ tion. -- .''`. 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