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:
pgpL1VK1Y1J18.pgp
Description: PGP signature