[Pkg-sysvinit-devel] Early RW filesystem mountpoint

Henrique de Moraes Holschuh hmh at debian.org
Sat Sep 16 16:10:33 UTC 2006


Well, I think we will need to ask a TC rulling for this one, given that
people could not decide on a name for it.

Here's the requirements for a early rw filesystem:

	1. Suitable mountpoint.   It needs to be created while the
	   system is in running state, and it needs to live in the
	   root filesystem.

	   This rules out all standard filesystem mountpoints, which
	   includes /var/*.  We cannot create a mountpoint under a
	   mounted filesystem.

	   If we remove the other non-suitable mountpoints because
	   of the FHS, we end up with (IMO):

		1a.	Place it in / directly
		1b.	Place it inside /etc anywhere
		1c.	Place it inside /lib anywhere.

	2. tmpfs support in kernel or loaded from initrd


If we use bind mounts and move them arround, that adds a minimum kernel
version requirement as well, which I have not tracked down.

I am for option 1c as our starting point, as 1a faces too much resistence
even for an upload to experimental (see previous flamewars about the issue).

I am also for pre-emptively requesting a decision from the TC about whether
we should use 1a or 1c, and how to name the filesystem.

While a TC decision isn't made, I suggest we use /lib/init/rw.  It is within
our namespace, and it is technically sound and not that ugly, so, should the
TC rule that we are to continue using it, we won't be so bad off :-)

To ease deployment and migration later to a TC-defined (or, dare I dream, a
FHS-mandated) mountpoint, I strongly suggest we define an environment
variable that tells all users of this filesystem where it is to be found.

I suggest we use "INITRWFS" as the environment variable name, and modify
whatever we must to have the hability to set that environment variable.  And
coordinating/supplying patches to all initscript subsystems should they need
it to enable the support.

I suggest we define that, for Debian, if this variable is not defined,
/dev/shm is to be used by the services needing an early-writeable
filesystem.   This is our solution for backwards-compatibility: patches
adding early-writeable-filesystem support will preserve the status-quo if
INITRWFS is not set, thus easing a lot the transition and patch acceptance.

What do you guys think?

-- 
  "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



More information about the Pkg-sysvinit-devel mailing list