Hi, On Thu, Mar 20, 2003 at 02:24:58PM -0500, Theodore Ts'o wrote: > On Thu, Mar 20, 2003 at 04:48:14PM +1000, Anthony Towns wrote: > > Is scanning all the partitions for their UUIDs once when the system boots > > such a problem? Or is the aim for people to be able to set the UUID once > > (with tune2fs or mk2fs referring to the device by name), then only have > > to use UUID later, and never have to scan at all? > > > > If you're ever planning on scanning, doing so once at bootup would seem > > entirely feasible. > > If you have a very large number of devices, doing the scan even once > could get very painful. Consider the case of 4000 block devices, and > needing to find the external journal device for the root filesystem > when the root filesystem is being fsck'ed. You really want to able to > refer to /etc/blkid.tab from the previous boot session to avoid doing > the scan. It's just a much more robust scheme. You could make the the same argument here you're making against embedded systems - why introduce a *mandatory* cache that *forces* a writable blkid.tab that's nothing but an optimization mechanism for gigantic systems (*thousands* of block devices? Tens, fine, a hundred, ok, but thousands? That's *definitely* a special case in my book). > And no, /etc/blkid.tab isn't necessary going to be static. For a > system with a very large number of disks, the possibility that SCSI > id's might get renumbered is a very real one --- suppose a disk dies, > or is removed from the chain? At that point you will want to do a > rescan, and then save the results to the cache. Well, if after some runtime failure the tools would be able to detect that the reality doesn't match the cache (just a speedup mechanism after all) anymore, they could rescan without saving if the cache is read-only, until a maintenance window is scheduled in which a rescan can update blkid.tab to reflect the changed disks. > > No, the whole point of /run is for it _not_ to have to be on the root > > partition, but, unlike /var, for it to definitely be local. > > /var is definitely local. To quote from the FHS: > > Some portions of /var are not shareable between different systems. For > instance, /var/log, /var/lock, and /var/run. That makes /var host-specific, but not necessarily on a local disk. > > Also unlike /var, but like /var/run, files in /run would not be > > persistent. > > And for writable files that need to be persistent and available before > other partitions are mounted? For that there's /var, and everything you currently need *available and writable* to mount /var can be easily generated before putting it on a fs that's cleared at each boot (template mtab from /proc/mounts, template resolv.conf from a static /etc/resolv.conf.default). So right now a read-only root is feasible. If you add the availability of *writable and up-to-date persistent data* to the current requirements for mounting /var, you'd make it definitely impossible. I think that closing that path for the future doesn't buy you that much; as said, if the tools could detect that the cache is out of date (by simply verifying whether the uuid on the device selected from the table by uuid matches that uuid) and drop the speedup, you may gain the advantages of having a cache without imposing new requirements to the root filesystem. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpT_lvdUycJK.pgp
Description: PGP signature