[Pkg-sysvinit-devel] Early writable filesystem

[Henrique de Moraes Holschuh]

Crap, I thought I had sent this one in, but it was still sitting in my
drafts folder.

On Tue, 27 Dec 2005, Thomas Hood wrote:
> 1. If we choose /run then the justification is that this makes an area
> available very early and is implemented easily, racelessly and with
> broad kernel compatibility.

Yes. And it doesn't break absolutely anything, since it is a new directory.
But people dislike new things in / so we will get some flak from it, and we
will have to propose it to FHS upstream.

We can't use /root/run (/root is a no-touch land, and probably critical)

/lib/run and /etc/run are technically just as good as /run, as long as the
mount points are created in the postinst (read-only / needs to be supported
as much as we can :-) ).

The oposition to /run did not provide any technical reasons for that being a
bad idea, so it is a question of preference.  And as far as preference goes,
mine goes clearly to /run :-)  It is by far the cleanest place to put that
filesystem in IMHO.

> 2. If we choose /var/run then the justification is that this makes an
> area available very early at the same location as is already used for
> storing state information later on.

How are we going to deal with a /var mounted on top of our /var/run?

Please correct me if I am wrong, but that would mean that:

 - it will require the filesystem to be mounted *somewhere* that is
   not /var/run (it has to be either a local disk or tmpfs, nothing
   else is really workable, and you cannot mount the same tmpfs twice
   so you have to stick it somewhere out of the way to move/bind to
   it -- and we must support diskless stations, so tmpfs it is).
 - we will have to mount --bind /var/run to that place
 - then something mounts NFS or something else in /var, and our /var/run
   is not accessible anymore, thus creating a window of opportunity for
   really nasty breakage (and a chokepoint on parallel boot)
 - we will have to umount the old bind-mount (which is now below /var)
   or leave it there to cause a lot of confusion, and mount --move/mount
   --bind /var/run again.

KISS is not always our best interest, but the above is ridiculously fragile
to my tastes.  Therefore, I do not think /var/run is acceptable.  IMHO we
should use /lib/run or /run instead.

That, and we'd also need to fix everything that dislikes an ephemeral
/var/run.  Which IMHO is something we should do anyway in Debian, but there
is also third-party software.

> 3. If we choose nothing then we can say that there was insufficient
> support in favor of any particular solution, and that there are
> alternatives to early writable filesystems.

But we know that boot logging, boot profiling and the stuff currently
misusing /dev/shm really have a good case for an early-writeable area, and
we want to use it ourselves for logging, parallel initscript states, etc...

BTW: it will also make advanced initscripts simpler, and that can only be a
good thing.

> I think that we should choose #3 unless we are all prepared to get
> behind either #1 or #2.

I am fully prepared to ignore anyone proposing #2 on the grounds that there
is a much simpler (technically) solution available (#1).  Unless I am wrong
in the points I raised above, of course.

Now, if I have to chose #3 or #1, I'd go with #1, and implement it in the
simplest manner possible too: create it with a SMALL amount of space (say,
no more than 512 inodes and 5MB), and *let it be*.  Deal with missuse in
policy, and the local admin can do whatever he wants, as usual.

WHERE to place #1 is the question. I'd just either formally ask the FHS for
/run and let people deal, or ask the secretary to run a vote (since the
Debian ctte is useless since we probably will never ever hear back from
them).

So, my vote is for #1 either in /run (if we all agree to it), or in one of
three options: /run, /etc/run, /lib/run which is chosen by a vote.

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