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. > 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? > [...] 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. 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. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
