Hi,
On Tue, Mar 11, 2003 at 07:45:10PM +1000, Anthony Towns wrote:
> On Tue, Mar 11, 2003 at 10:10:59AM +0100, Emile van Bergen wrote:
> > No, but it does make sense to have a tmpfs of which parts are preserved.
>
> Depends. If you want to do it for all Debian systems, that'll require
> patching boot-floppies, doing lots of compatability code to upgrade
> existing installs without breaking things, and so forth. If you just
> want to do it for your systems, or even make it an option that people
> can easily choose at install, that's easier.
Well, the tmpfs part is optional, not mandatory to make it functional
for the purpose of having it writable early and cleared at bootup, if
there's another filesystem such as root or /var that is writable early.
The prioritised choice is as follows:
1. if /dev/shm is available, then /mem is a symlink to /dev/shm/mem,
and at bootup we
mkdir /dev/shm/mem
2. else if tmpfs or equivalent is available (older kernels or *BSD),
then at bootup we
mount -t tmpfs /mem
3. else if root is writable very early, then at bootup we
rmdir /mem
mkdir /mem
4. else if /var is writable very early, then /mem is a symlink to
/var/mem, and at bootup we do
rmdir /var/mem
mkdir /var/mem
So I see more than enough possibilities to avoid breaking things.
You don't need tmpfs on boot-floppies if either / or /var are available
early enough. Just make sure /mem is empty at bootup.
> > > Calling it "/run" allows us to:
> > > (a) just leave it as a directory on /, presuming / will be mounted
> > > rw. Simple, obvious, no effort required!
> > > (b) we can also symlink it to /var/run/early if /var is a local fs
> > > (c) if someone wants, they can make it tmpfs, or whatever themselves
> > > Calling it "/mem" would be confusing in either (a) or (b). If someone
> > > wants to mount /var/run as tmpfs, that's their choice, independent of
> > > any of this.
> > Why would you want (b) at all?
>
> We don't have tmpfs compiled in, / is read-only. I'm sorry, maybe I wasn't
> clear:
>
> rmdir /run
> ln -s /var/run/early /run
Ah, yes. Well, if /var is the earliest filesystem to be available
read-write, you could achieve the same effect if you ln -s /var/mem /mem.
In order to still have an early empty part, an somewhat later
initialized part and a preserved part at shutdown, you could init /mem
from somewhere else than /var/mem as I proposed at first, eg. from
/var/state/mem, and save /mem/preserved back to /var/state/mem/preserved
instead of to /var/mem/preserved at shutdown, so that /mem can be a
symlink to /var/mem during normal operation.
> > just have /run as a symlink to /var/run
>
> It'd be safer to keep the namespaces separate, IMO.
Hm, yes, but would you then agree that /run has a broader purpose than
/var/run?
I also think so, and that's why I proposed /mem as a superset of
(/var)/run and therefore under a different name than /run.
The sets as I see them are as follows:
/mem is a superset of .../run, therefore .../run exists inside /mem
/mem/* is a superset of /mem/initialised-files-when-var-online
/mem/initialised-files is a superset of /mem/preserved
> Note that there's nothing stopping *you* from setting up /mem as a tmpfs,
> and linking /var/run, /var/log, /run and so forth to it, and preserving
> them on reboot (or backing them up from cron) as you feel appropriate.
>
> We could, I think, start using /run today, by:
>
> (a) adding it as a directory to sysvinit
> (b) arranging it to be cleared in early startup scripts
True. The same goes for /mem though, and because it's a bit broader than
/run, I still think it's named more appropriately.
Especially because of what you said, I think /run is only suitable if it
contains the same type of things as /var/run, with the only difference
of /run being guaranteed to be the earliest writable directory on the
system.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpUBye3TPxZ4.pgp
Description: PGP signature