Re: Proposal: /mem (was: Re: ifupdown writes to /etc... a bug?)
(as this is no longer really relevant to the original bug, i've removed
the CC:)
On Tue, Mar 11, 2003 at 01:48:57AM +0100, Emile van Bergen wrote:
> Shared vs. non-shared is not the point;
Well, you said that the contents of /mem were "only valid in the context
of the current kernel", which I (mis-)extended as "all the information
that is only valid in the context...", which would be the case anyway.
IMHO nothing that is truely specific to the local running kernel
("unsharable") won't fit perfectly for this new directory.
> All this trouble, different per storage scenario, just to get a
> directory of which the sole distinguising property is that it is
> writable before /var, is not worth it IMHO.
My point of view wasn't just getting it writable early, but also contain
everything regarding the local machine, which would be useful to get
into something different than /var, which could then be shared between
different running, to have "clone" machines (same dpkg state, same apt
cache, same nethack scores, same email, ...).
The mess resulting in supporting different storage media isn't
unavoidable. The difference between a ramdisk and shmfs, which we would
have to support anyway, is much greater than between ramdisk and a disk
partition.
> I assert that it is always OK for a writable directory that is used for
> this work to be small and held in main memory.
>
> I assert that a directory that is held in main memory during normal
> operation is useful.
I agree. But nothing should be restricted unless it's really necessary
to do so, don't you think ?
> It is useful because it has the property that it is guaranteed to be
> cleared on startup, which makes it better suited than /var for things
> that are now cleared manually.
One could mkfs the /mem partition at each boot, which would be necessary
anyway for a ramdisk.
> A small in-memory filesystem has the property that it won't spin up your
> disks, so a laptop administrator can move things that are frequently
> written to there, even if they must be preserved across reboots if you
> add a cp as part of your startup- and shutdown procedures -- as long as
> they are not important enough to be preserved if the system crashes.
>
> An in-memory filesystem has the property that it's fast, so if you have
> the memory available, you can create a /mem/tmp and set TMPDIR to it
> before running TMPDIR-intensive things such as sort(1) or cc(1).
I agree that having /mem in memory is a good thing, i just think it
shouldn't be required (obviously /mem would be called something else).
> > 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.
>
> I hope you aren't using "shared" as "networked", although I'm starting
> to worry that you do.
Well, don't worry ;)
> By definition, /var holds machine-specific data and therefore cannot
> be shared.
Which IMHO is wrong, see above.
> The point is that /earlywritable can not be networked on a network that
> requires ifup. That's the reason why you'd need it on a local disk or a
> writable NFS root. It has nothing to do with it being shared or not.
The data that can be shared doesn't need to be available early. The
early avaiability seem to be only a problem for unsharable things like
the ntp drift file, ifstate, mtab.
> Why? It's not required, but a natural match, and it's handy if you know
> a certain directory to be on a memory fs.
Let's say "is usually expected to be on a memory fs", then.
> I agree that the only required properties for something that's useful
> for ifstate, pidfiles, locks, mtab, temporary fifos, sockets, et al. are
> that it's
>
> * writable early, before /var is online;
> * always cleared at bootup - at least part of it.
>
> However, if you look at a few other desireable properties of a directory
> that's always on a memory fs:
>
> * not dependent any writable local disks;
> * not dependent on a writable (NFS) root filesystem;
> * all writable real filesystems directories may be on networks that use
> ifup and therefore need a writable ifstate;
> * part of it is saved at shutdown, a possibly larger part restored at
> startup;
> * you get a directory that is known to be fast and to generate no I/O if
> it exists, regardless of your storage configuration.
>
> > 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.
>
> It's not a big problem, but it does require you to make / readwrite
> eventually, quite early even. Mounting shmfs on /mem allows you to have
> a writable filesystem before and while / is checked or repaired.
I doubt devfsd or loading the keymap or whatever of this sort will
someday need to write anywhere...
> I see your point, but I see volatile as the rule here, and preserved as
> the exception. Also, a /mem of which only /mem/volatile is indeed in
> main memory is named a bit inappropriately IMHO.
Obviously a change in the concept implies a change in the name. I used
/mem and volatile just because i was too lazy to find something else ;)
--
Jeremie Koenig <sprite@sprite.fr.eu.org>
Reply to: