[Pkg-sysvinit-devel] Bug#390184: initscripts: please limit the size of /lib/init/rw

[Petter Reinholdtsen]

[Roger Leigh]
> These two filesystems serve fundamentally different purposes, and
> namespace collisions between those two uses should be avoided at all
> costs -- by keeping them completely separate.

Perhaps.  /dev/shm/ is well defined and out of scope for how dosemu
and user-mode-linux uses it, while /etc/init/rw/ is new and can be
used for what we decide to use it for. :)

> Is there any good reason to combine the two?

The reason I see is to limit the amount of mounted tmpfs partitions to
one, to reduce the risk of spending all of memory on them. :)

> Please don't do this.  Sensible defaults are all that is required in
> both cases.  For /lib/init/rw, this could most likely be set to a
> tiny amount, like the 100 KiB suggested.  For /dev/shm, requirements
> could be a lot higher, and vary from system to system, but again a
> sensible default would fix this.

Why should /dev/shm/ be so high?  There are almost no application
using the shm*() functions in glibc.  Which one of these need a large
file?

> The current practice of using the kernel default of 0.5*coresize is
> wrong.  I'm currently safe, having a good 6 GiB of swap, but for high
> memory systems with less swap than core, you're heading into potential
> DoS territory with the current approach.  On a system with 8 GiB of
> core, a 4 GiB /lib/init/rw is a waste and a huge liability.

I believed unused tmpfs space wasn't taking up any space in the
kernel.  Is this not so?

> Suggestion: choose fixed limits, and allow the user to configure both.
> /lib/init/rw could be fixed to a specific size, and /dev/shm could be
> e.g. 0.5*core up to an upper limit of 512 MiB (by default).
> 
> The current SHM_SIZE in /etc/default/tmpfs is no longer sufficient.
> Please could you add an INIT_RW_SIZE in addition, and set it
> by default?  (As in the patch).

There is a variable RW_SIZE allowing you to set the size of
/lib/init/rw/.  It was introduced in version 2.86.ds1-24.

> Also, given the widely differing sizes of the various tmpfs
> filesystems, TMPFS_SIZE is not really all that useful any more.
> Could this be deprecated or removed?

Well, it is not obvious to me that the various tmpfs file systems do
have widely different size requirements, so I do not plan to deprecate
it myself.

Friendly,
-- 
Petter Reinholdtsen