[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: New required package: libblkid1


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.



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

Reply to: