[Pkg-sysvinit-devel] Early RW filesystem: PROPOSAL AND VOTE REQUEST

[Henrique de Moraes Holschuh]

On Mon, 18 Sep 2006, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> > Please reply with your thoughts, and whether you agree with this or
> > not.  Let's get this over quickly, if at all possible...
> 
> I am starting to conclude similarly, that we need to provide some
> other writable location early in the boot, and is considering if it is
> possible to make tmpfs on /var/run/ and /var/lock/ a new option in
> /etc/default/rcS.  But I am not yet sure if the last part is feasable.
> I agree that we for the short term should revert the /var/run/ and
> /var/lock/ changes, to avoid blocking the fix for an early writable
> tmpfs because of the /var/run/ controversy.

Ok, that's two votes for the new plan (mine, yours).

> One thing we need to consider is what to ask the previous users of
> /dev/shm/ to use if /var/run/ and /var/lock/ isn't available for their
> use.  Shall we ask them to use /lib/init/rw/?  Shall we umount
> /lib/init/rw when the other file systems become available?

Those are easy to answer.  We can't just umount it after early start, unless
all code that uses it moves it data to some other place by itself, so far so
good.  Linux kernel 2.6 would let us move the filesystem itself elsewhere,
but requiring 2.6 for just that is not exactly justified, and it would
complicate matters for other kernels too.  Not to mention it would need to
become /var/run or something else like that, which would tie it to the whole
/var/* being tmpfs again.

The filesystem's use should be limited. A small size takes care of that,
along with proper policy rules and a heavy cluebat: we make it clear that
the early write filesystem is off-limits to anything that doesn't start
before /var/run is made available.

Note that coldplug stuff is among the ones allowed to use the early
read-write filesystem.

We *can* get rid of it later in the boot process, but if we do that (and it
does imply every user of this filesystem needs to be able to move its data
somewhere else before we umount it), let it be for its own technical merits
and NOT just to avoid misuse.

And yes, we definately should get everything touching /dev/shm that is not
glibc to stay the hell away from /dev/shm.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh