Re: Proposal: /mem (was: Re: ifupdown writes to /etc... a bug?)
On Mon, Mar 10, 2003 at 09:23:42PM +0100, Emile van Bergen wrote:
> > To have the possibility (on small, possibly diskless systems) to consume
> > memory at boot only, then to move to cheaper storage? In some situations
> > each byte counts...
>
> True, but environments that are so constrained that they cannot even
> hold simple state/pid files in virtual memory tend to have very custom
> initialization/shutdown procedures anyway.
Right, i was just trying to catch the logic.
> I think that there is a whole class of problems that would benefit from
> /mem; every small file whose contents are only valid in the context of
> the currently running kernel, which must now be explicitly cleaned at
> startup.
>
> I.e. everything that refers to processes (locks and pidfiles), network
> interfaces (ifstate), mounted filesystems (mtab), nfs export states,
> etc. etc.
Well, I think this boils down to splitting /var in two pieces : sharable and
non-sharable between systems (is this what you mean ?). I think it would
make sense and be useful. Storing the non-sharable part in a ramdisk
seems reasonable and a good default for most situation. But the
underlying media should only be required to have some properties (being
mountable early in the boot process, for instance).
> That you can make /mem available immediately when the kernel is up and
> you can access /bin/mount is basically just a nice bonus that happens to
> solve the writable-ifstate-before-networked-var-online problem.
I think i'm starting to get the point. Let's have a try :
We want a directory that hold file that need to be changed automatically
by the system, just as /var does. However, it would contain the part of
/var that is directly related to the local system and can't be shared.
Consequences : since it is small by nature, it can be required to be
available early in the boot process, which solves some problems. A good
part of its content is not meaningful to keep between shutdown and boot,
and can be cleaned up efficiently, and the filesystem may even be
recreated at each boot (which include using a ramdisk), having the part
intended to be preserved archived somewhere before shutdown, and
restored while booting up.
Or have I missed something again ?
> > Maybe something like /var.early, /var.boot ? This would more adequately
> > reflect the spirit (at what i think is the spirit) of the whole thing,
(please read "_or_ what i think...)
> > and would less "philosophicaly" hurt FHS compliance..
>
> I don't see why /mem would philosophically clash with the FHS more than
> /var.early and /var.boot, which are top level directories with /very/
> limited applicability - which I'd say conflicts more with the spirit of
> the FHS than new top level directories covering a broader range of
> purposes.
Quite true, my point was creating another instance of /var available
early, just as /bin is available early and /usr/bin is not. Hurd guys
would have made /var.early a symlink to /var ;)
But /usr is meant to be suited for read-only data, just as the one in
/boot, /lib, ... Something is missing.
> /mem is a simple, general thing with an easily defined lifecycle, an
> obvious name (resides in memory, part of it is preserved) and is IHMO a
> useful addition to any *n*x.
>
> And, it solves the ifstate problem in a cleaner way than copying parts
> of /var between different flavours of /var during startup/shutdown. No
> copying is needed and the semantics are very clear:
>
> * mounted (readwrite) as soon as possible
> * as soon as /var is available, a cp -Rp /var/mem /mem is done
> * at shutdown, a cp -Rp /mem/preserve /var/mem/preserve is done
Well, the "resides in memory" part still sounds bad for me. I agree that
it would be meaningful to require /mem (or whatever it sould be called,
that's not the problem) to be storable onto a ramdisk. I don't think it
would be fair to require it to _be_ stored in memory.
Maybe swapping the preseved/volatile parts may be meaningful, too :
- /mem/volatile (or something) is not preserved.
- anything else in /mem is
This way it would be possible to mount a ramdisk/shmfs into
/mem/volatile, and leave /mem in the root filesystem. Since everything
readonly until disks have been checked is not a big problem, /mem
readonly until / has been checked shouldn't be one either.
Of course, it should still be possible to have /mem into a ramdisk
(possibly installing some package to do its initialisation from /var/mem
or whatever), so your disks stop spinning ;P.
--
Jeremie Koenig <sprite@sprite.fr.eu.org>
Reply to: