Hi there!
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:
>> On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote:
>> > Josh Triplett suggested that we could use a single tmpfs on /run and
>> > have the rest as symlinks into /run, with potentially a separate
>> > tmpfs for user-writable filesystems to prevent a user DoS. This idea
>> > does have merit, and we could make it the default. We currently do
>> > this for /var/lock (/run/lock), which can be mounted as a separate
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > tmpfs on /run/lock if RAMLOCK is set in /etc/defaults/rcS.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Do you mean that the meaning of RAMLOCK has completely changed?
>> Currently, `man rcS` gives:
>>
>> RAMLOCK
>> Make /var/lock/ available as a ram file system (tmpfs).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
>> I consider completely changing it a serious bug, may I suggest
>> deprecating it completely and adding a new variable instead? I guess
>> the same should be applied to RAMRUN, i.e. simply deprecate it.
>
> With the patch as it stands at present, RAMRUN is deprecated. /run
> is always a tmpfs; RUN_SIZE will set its size, as before.
Fair enough and, FWIW, fully agree.
> RAMLOCK is unchanged, except for the fact that it's mounted on
> /run/lock rather than /var/lock.
No, /var/lock changed *substantially*, given that it is now *by default*
(on) a tmpfs, regardless if RAMLOCK is set or not. Which means that
RAMLOCK as it was explained is useless, thus my question about your
words underlined above: "which can be mounted as a separate tmpfs on
/run/lock if RAMLOCK is set in /etc/defaults/rcS".
I do not have any idea which variable could be straightforward,
something like LOCK_OWN_TMPFS...
> Likewise, LOCK_SIZE is unchanged in its meaning.
Again, I found it changed: how can you define LOCK_SIZE if /run/lock is
on the same tmpfs than /run?
> We could introduce new variables for /run such as RUNLOCK, but given
> that it does exactly what it used to do, I don't think it gains us
> anything.
Fully agree, and FWIW it was not what I was asking for ;-)
Thx, bye,
Gismo / Luca
Attachment:
pgpcZfxAWQ6vC.pgp
Description: PGP signature