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

Re: RFC: New required package: libblkid1



On Thu, Mar 20, 2003 at 09:30:11PM +0100, Emile van Bergen wrote:
> 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).

It's not a mandatory cache.  If the cache isn't present, or has been
proven to be out of date (after looking up the block device for a
particular UUID or LABEL, the blkid library checks to make sure the
information is accurate before returning it), then the blkid library
will scan all of the devices in the system.  If the root filesystem is
read-only (such as will be the case when the root filesystem is being
fsck'ed), then the cached information simply won't be saved to disk
and discarded.

So for an embedded system with a read-only root, you can either freeze
the /etc/blkid.tab file with the correct information, or you can just
not have the file present in /etc.  The blkid library will work
correctly; just not optimally.  (If you think about it, it *has* to be
that way, since the root filesystem is mounted read-only initially,
and the blkid library has to be able to accomodate that case.)

> 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.

We're certainly not closing the path for the future.  And for this
reason, this discussion is somewhat academic.  There are other
packages that currently have writable files in /etc (such as ntp), and
in order to make this change you're going to have to go get changes to
the FHS anyway (because of files like /etc/mtab and /etc/adjtime,
specifically called out in the FHS to live in /etc).

So you'll have to get FHS approval, and then other packages will have
to be modified, and if necessary, the blkid library can be modified to
accomodate a read-only root (at least for systems with a small number
of devices.  A system administrator who wants a read-only root and a
large number of disks is going to suffer, but he/she is just being
silly, and will pay the price in many and sundy ways.  :-)

							- Ted



Reply to: