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

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



Hi,

On Mon, Mar 10, 2003 at 11:19:39PM +0100, Jeremie Koenig wrote:

> On Mon, Mar 10, 2003 at 09:23:42PM +0100, Emile van Bergen wrote:
> 
> > 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).

Shared vs. non-shared is not the point; everything may currently assume
/var is non-shared and I see little benefit in making it possible to
share parts by splitting /var into a shareable and non-shareable part.
(To avoid confusion: "shared, ie. used by multiple machines" and
"mounted over the network" have very little to do with each other).

The point is that /mem is writable early in any storage scenario, even
with no writable local filesystems, even with a read-only NFS root and
/var not yet mounted because it resides on a different network, which we
can access only after doing ifup.

If you go for a /earlywritable that must be on real storage during
normal operation, it may initially still have to be on an in-memory
filesystem in order to satisfy the early writable requirement, so that
the contents must be copied, the directory unmounted, removed and
subsequently symlinked during the startup procedure to satisfy the
requirement that it is on real storage during normal operation. The word
"brittle" springs to mind here.

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. There is only very little
work that needs something writable before /var itself is mounted
read/write.

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.

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.

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).

> > 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.

I hope you aren't using "shared" as "networked", although I'm starting
to worry that you do. By definition, /var holds machine-specific data
and therefore cannot be shared. Of course it can still be mounted over
NFS.

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.

[SNIP]

> > /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.

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.

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 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.

Cheers,


Emile.

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

Attachment: pgpmEqsf27P16.pgp
Description: PGP signature


Reply to: