On Mon, Dec 19, 2005 at 12:23:00PM +0100, Thomas Hood wrote: > Steve Langasek wrote: > > Are there really any init scripts that need to write out data prior > > to checkroot.sh (the point at which /run would be writeable by > > default on the rootfs)? > Well, it would be nice if fsck logs could be stored in /run until > /var/log/ is available for writing. It would be nice if mtab could > be kept in /run so that it could be written to as filesystems are > being mounted. Currently these sorts of things are delayed using > one trick or another. Ok, that's fair. > > by constraining the actual *implementation* of /run (barring ugly > > hacking of the init scripts), you've made the system less suitable > > for a third use case: > > > > - memory is at a premium, disk is not > Tmpfs memory can be swapped out, so is this even a hypothetical problem? Maybe it isn't on Linux. I wasn't aware tmpfs could be swapped out. That still leaves the question of just which features we want to require from our non-Linux kernels for basic operation, I guess. > > [...] the point is that design-wise, there's simply no reason > > to make the choice for the user of *what* is mounted on /run, only > > to specify that *something* must be (and that it must be writable); > One advantage to supporting only tmpfs on /run is that the assumption > can then be made that the hierarchy is empty at boot; there are no > stale files and no cleaning has to be done. Seems to me that we have a handle on the process of cleaning directories by now though, no? :) > If there are reasons why some users would not want to put a tmpfs at > /run (which there may well be, although I haven't heard them yet) > then we can of course support this. Then either initscripts will have > to clean the directory or programs using it will have to contend with > stale files. Cleaning cannot occur until the filesystem underlying > /run is mounted read-write and programs must not use /run before the > cleaning has been completed; it would probably be easier to drop the > cleanliness-at-boot guarantee and let programs clean out their own > stale files. Sounds to me like this will play havoc with idempotence of init scripts; anyway, why would "mount /run and clean it" be anything less than an atomic operation from the viewpoint of other init scripts? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature