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

Re: RFC: New required package: libblkid1



On Wed, Mar 19, 2003 at 11:40:47PM -0500, Theodore Ts'o wrote:
> It's one line per block device, and it's in XML format:
> <device DEVNO="0x0302" TIME="1047622800" LABEL="root" 
...       UUID="60cc84b5-f7df-43e6-b6f3-268cdef48de1" 
...       SEC_TYPE="ext3" TYPE="ext2">/dev/hda2</device>

> If you have a system with 2000 block devices then the blkid.tab file
> will be around 160k, but that's not going to be the typical case.  But
> in that case where you have 2000 block devices, (A) you really want to
> use UUID= or LABEL=, since managing that number of devices is not
> pleasant, but (B) the implementation of searching all block devices
> when using UUID= and LABEL= is really painful.

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.

> I ask you: what specific problem does creating a new top level
> directory solve, other than making the making the anal-rentative FHS
> lawyers happy?  

I just love the way Debian lists bring out the best in people.

The problem it solves is it removes obstacles that stand in the way of
mounting / read-only.

> /run and /etc have to be on the root partition, 

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.

> and the files need to be persistent, 

Also unlike /var, but like /var/run, files in /run would not be
persistent.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Dear Anthony Towns: [...] Congratulations -- 
        you are now certified as a Red Hat Certified Engineer!''

Attachment: pgp8Z8k0utpQR.pgp
Description: PGP signature


Reply to: