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

Re: ifupdown writes to /etc... a bug?


On Wed, Mar 12, 2003 at 07:19:16PM -0500, Joey Hess wrote:

> Emile van Bergen wrote:
> > > Then you are probably second-guessing the kernel's disk caching, and
> > > should be using /tmp or something instead.
> > 
> > The difference between /tmp and a mode 1777 directory in /mem is that
> > the capacity/speed tradeoff may be different for each. 
> With a large emphasis on the "may". /mem may be in swap, and the kernel
> may decide to keep everything you write to /tmp in cache. So indeed they
> may have inverted properties to what you might assume.
> I have never seen a program in all of Debian that legitimatly needs a
> ram disk for faster file operations. I've never even run upon one that
> claims it needs such a thing. I think your /mem is a solution in search
> of a problem.

/mem/tmp alone would be, yes.

But the combination of /mem, /mem built from a skeleton at bootup,
/mem/run, /mem/preserved that may be copied back and *possibly* a mode
1777 /mem/tmp, is a solution for:

- the ifstate and/or dhcp vs. networked var problem
- things that must be cleaned at boot
- less important differences between tmpfs, shmfs, ramfs and ext2-on-ramdisk
- readonly / or /etc
- laptop disk spinups
- applications that think they're smarter than the kernel in deciding
  how long their files should live and whether it should ever go through
  block allocation on a disk-based fs. (Whether they're right in that
  should indeed be judged on a per-application basis).

None of these things on their own may be important enough to implement a
/mem for, but taken together I think it's worth it, especially because
it's a relatively elegant and generic solution for these problems, and
because it's easy to implement.

I'm implementing it in three scripts right now.

The first one is an /etc/init.d/mountmem, intended to be linked to from
/etc/rcS.d/S09mountmem (just before checkroot), that mounts /mem either
as tmpfs, shmfs, ramfs or ext2 on /dev/ram0 or /dev/ram1, depending on
what's available, or not at all; SLASHMEMTYPE in /etc/default/rcS can
be used to specify the types to be tried in any desired order. 

The second is /etc/init.d/initmem, that empties and inits /mem --
whatever it is, wherever it is -- from a skeleton at startup, and is
intended to be linked to from /etc/rcS.d/S36initmem.sh.

The third is /etc/init.d/savemem, that saves /mem/preserved back to
its corresponding directory in the skeleton, and is intended to be
linked to from /etc/rcS.d/S301savemem, between S30urandom and

When I'm done, I'll put it on a webpage, so everyone can have a look for
himself. I'll stop trying to convince you all now; as I implement the
solutions using /mem for the problems above I'll let you know how it
works out.

EOT, for now.



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

Attachment: pgpsBm6ioCyIW.pgp
Description: PGP signature

Reply to: