Hi, First I want to say that /run is very much OK to solve the problem at hand; it's just a pity that we decide to add a top-level direcory with a such a very limited purpose. On Tue, Mar 11, 2003 at 11:18:08PM +0100, Thomas Hood wrote: > > 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. Correct. A ramfs is not /required/ to solve these problems, just an elegant way to solve them. A filesystem with ramfs-like properties is useful. A filesystem that's /likely/ to be ramfs is more useful than a filesystem of which you know little other than that it does what's needed to solve the issue of ifstate and mtab. /mem has more purposes than /run and is the most elegant way to implement /run (as /mem/run). Therefore it's a better candidate for a top level directory than /run. Top level directories should be planned with foresight, not with limited purposes in mind - you don't want too many of them after all. > 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. Perhaps. However, I think that were naming according to *properties* (not to implementation -- as said, no particular filesystem type is /required/, implementations can be disk + rm, tmpfs, ext2 on ramdisk, shmfs) is possible, the name will make sense for longer than a name according to purpose. Naming according to purpose has brought us /etc and /usr. These names have no relevance whatsoever today. At least with naming according to properties you don't run that risk. > 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? I agree that /var/run and /run doesn't have to be used for the same things for to be named similarly, but if the namespaces should be kept separate (as Anthony Towns said) meaning /run should not be a symlink to /var/run on systems that have /var available early enough, then to me this indeed suggests that /run is to be used in a /broader/ way than /var/run, instead of a /narrower/ way, as is the case with /lib vs. /usr/lib, /bin vs. /usr/bin, etc. > 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. Yes, *if* you make a top-level directory with the *sole* purpose of being available for writing early, then your guess seems correct. > One will only need to use a ramfs on a diskless workstation. /Need/ is the keyword here. It's /useful/ in other places as well. /run/ is just one of the things it's useful for. Also, I think I rather have the filesystem type of such a general purpose directory depend on what the kernel offers than a seemingly unrelated issue such as on which network /var is located in my setup (same as NFS root or on one that needs ifup/dhcp?). > On the other hand, one will want to avoid a ramfs on a limited-memory > system. I True, but even a single megabyte of memory would be overkill for such a filesystem. And if shmfs is used, it'll match the size of whatever's stored there. Limited memory is 16 Mb; heck dselect thrashes your disk to hell on such as system. It'll have no problem sparing a few Kbs for ifstate and pidfiles and my ntp.drift. The files are not pinned in RAM either. Pages that are accessed infrequently enough will go to swap on a modern tmpfs. > 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. Sorry, I don't follow. If it's a natural for /some/ things to be stored in virtual memory rather than on real media, why would you rather suggest hacks such as noflushd to keep /all/ things written to real media in RAM for longer? Is that elegant then? The OS can never be smarter than the applications or the admin in deciding which data should be flushed early and which doesn't. > 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. What you need after a crash is your /var/log, not a bunch of pidfiles. When Debian reboots now, it'll also happily empty /var/run, empty mtab, clear ifstate now as well, even after a crash. I don't see a problem with that. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgp0UvRuYjl9s.pgp
Description: PGP signature