Re: ifupdown writes to /etc... a bug?
It is now clear to me that the question about creating /mem
containing a fs that is RAM-based-if-possible is orthogonal
to the question about creating a runtime state directory that
is rw, persistent-until-reboot, and network-independent.
/mem is neither necessary to solve the runtime state problem
nor sufficient to solve it in every case. The most that can
be said is that it would be useful, sometimes, in solving
this and other problems.
Given this orthogonality, I suggest that the /mem debate be
carried on in another thread.
In *this* thread I am proposing that /var/run should be the
standard path to our runtime state directory and that it should
be a symlink (both before and after /var is mounted) to another
directory that is rw, persistent-until-reboot, and network-
independent.
If the conclusion of the other debate is that /mem will be
created, then it is open to us to decide that /var/run should
be a symlink to /mem/run. If the conclusion of the other
debate is that no /mem will be created, then it is open to us
to decide that /var/run should be a symlink to /run or to
/dev/shm as appropriate.
On Wed, 2003-03-12 at 15:47, Emile van Bergen wrote:
> > - need shared memory? use /dev/shm
>
> I suspect that if you want a filesystem interface for a bit of memory,
> you don't require it to have /dev/shm's exact semantics in the majority
> of cases, but can make do with any mmap'able file, be it on tmpfs,
> ext2-on-ramdisk or whatever; you just want to avoid I/O if at all
> possible.
>
> A /ram or /mem that would point to /dev/shm when available or to a
> tmpfs, ramfs, ext2-on-ramdisk, or whatever your kernel offers otherwise,
> would allow applications to use a filesystem interface to memory
> regardless of kernel version or type.
>
> > - need to put info somewhere that doesn't have to be kept between
> > boots? /var/run
> > - same but need it before /var is mounted? /run
> > - same but need it even when / is read-only ? /run, setup by the
> > sysadmin to be on a tmpfs
>
> So what do I do when I'm writing an application or script that likes to
> use a ram-based fs if any is available? Test for /dev/shm first, then
> see if we're lucky enough to be on a system that has /run on tmpfs,
> otherwise bug the admin to create a separate tmpfs? It's messy, and
> requires each application to do these tests in order to take advantage
> of an already mounted tmpfs.
>
> I think /ram or /mem (perhaps still better because /ram seems to imply
> it'd never swapped out) would also simplify the choices you outlined as
> follows:
>
> - need exact /dev/shm semantics? use /dev/shm
>
> - need any type of storage really, but preferrably ram-based? use /mem
> (alternatively: need any storage, as long as it's ram-based? use /ram)
>
> - need to put a small amount info somwhere that doesn't have to be kept
> between boots? use /mem (or /ram). The the type of / or /var is irrelevant.
>
> - need to store a potentially larger amount of info, and don't mind to wait
> until /var is mounted? use /var/run.
>
> Again, your proposal is fine, but I still think offering a generic ram-based
> fs is more elegant.
--
Thomas Hood <jdthood0@yahoo.co.uk>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Reply to: