Re: ifupdown writes to /etc... a bug?
The name chosen for the new directory does matter. Is the
directory essentially a ramfs which can be used for storing
runtime state and for other purposes, or is it essentially a
place for runtime state which can be implemented on a ramfs
or in other ways? The origin of the present discussion was
the observation that we need the latter in order to solve
a real problem that arises from shortcomings in the current
standard FS hierarchy. A ramfs has many nice features, but
it isn't actually *required* in order to solve the problems
that have been raised in this thread. What is required is
a place to store runtime state that doesn't require a network
to exist and which will allow people to mount /etc readonly.
The existing standard directory hierarchy has been named
according to the purpose of the directory rather than
according to the implementation technology, and I think we
should follow that precedent. For now I'll continue to
suggest "/run" but perhaps a better suggestion will come along.
The argument that it can't be called "/run" because it won't
be used in exactly the same way as /var/run isn't very
persuasive. Is /lib used in exactly the same way as /usr/lib?
On Tue, 2003-03-11 at 11:51, Emile van Bergen wrote:
> Well, I stipulate that /mem will be in memory in 90 % of the cases if
> implemented, and exhibit memory-fs-like qualities in 100 % (gone at
> reboot, except for an explicitly preserved part).
I doubt that. My guess is that on 90% of systems, /run or
/whatever will simply be another directory on the root filesystem,
since that is the simplest way to implement it on ordinary
standalone machines, and completely adequate. One will only need
to use a ramfs on a diskless workstation. On the other hand,
one will want to avoid a ramfs on a limited-memory system. I
don't see any general performance advantages to a ramfs in
implementing this directory. No disk spinups on modifications
to ifstate, mtab and pidfiles is a trivial advantage whose
importance is reduced in the presence of noflushd and such.
Not having to do a "rm -rf" to clear the directory is a trivial
advantage, counterbalanced by the fact that the contents are
not available for debugging purposes after a crash.
--
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: