[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposal: /mem (was: Re: ifupdown writes to /etc... a bug?)



Hi,

On Mon, Mar 10, 2003 at 07:59:25PM +0100, Jeremie Koenig wrote:

> On Mon, Mar 10, 2003 at 06:00:31PM +0100, Emile van Bergen wrote:
> > Good idea, but why copy it over and unmount it at startup instead of
> > shutdown?
> 
> 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.

> > * keep /tmp as it is now;
> > * keep /var as it is now;
> > * add /mem, which is RAM-based, writable /very/ early, and initialised
> >   in full from /var/mem at bootup, allowing the admin to define a desired
> >   initial state;
> > * have part of it, eg. /mem/preserved, written back to /var/mem/preserved at
> >   shutdown.
> 
> Why would it need to be in memory anyway ? Let's say "writable /very/
> early" alone (and use something else than /mem as the name). All we need
> is in fact only an early writable /var for a few specific boot-time
> things. 

Exactly because a very early writable /var.boot is only usable for a few
specific boot-time things, whereas my /mem proposal is usable for
different problems as well as the one under discussion.

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.

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.

> This is the kind of problem where something like unionfs would be
> welcome. Everything could just be in /var, with some files available
> earlier.

Let's hope, no pray, that it's still easier to amend the FHS than to
have unionfs implemented and adopted universally. 

> > [snip]
> 
> > I think /mem/ is cleaner than /var/mem, because the latter either
> > requires /var to be already mounted readonly, which sort of defeats the
> > purpose, or a lot of messy and fragile data movements at startup. 
> 
> 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,
> 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.

/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

Cheers,


Emile.

-- 
E-Advies / Emile van Bergen   |   emile@e-advies.nl
tel. +31 (0)70 3906153        |   http://www.e-advies.nl

Attachment: pgpoeEkAJjcKy.pgp
Description: PGP signature


Reply to: