Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Andries Brouwer]

On Sat, Sep 13, 2003 at 05:27:23PM -0400, Jeff Garzik wrote:

> IMO, we need to move users from a [probe-]order-based device and bus
> enumeration to some system based on unique ids.  I'm of the opinion
> that _both_ block devices and filesystems need some sort of GUID.
> Luckily, a lot of blkdevs/fs's are already there.
> 
> If you look at current usage out there, order isn't _terribly_ important
> given today's tools (such as LABEL=).  More important IMO is figuring
> out which spindle is your boot disk, and which is your root disk.
> Red Hat handles root disks by doing LABEL= from initrd.  But discovering
> the boot disk is still largely an unsolved problem AFAIK...

Such things are infinitely difficult.
Moreover, great care is needed - one has to define precisely what it
is this GUID is supposed to be an ID of.

(Is it the ZIP drive? Or is it the ZIP disk?
The 2.4 USB code is broken because it remembers a GUID and thinks that
identical GUID implies identical disk.)

I have a handful of CF/SM cardreaders.
Some of them have no form of ID. Others have an ID.

Then one can insert a CF or SM card into the reader.
Some of these cards have an ID. Some have not.

On the card one usually finds a FAT filesystem.
There may be a label. Or there may not be.

This describes a 3-level situation.
I have also 4-level situations, where the reader is filled with
one of four auxiliary adapters (each with an own ID) and the
adapter then get a CF/SM/SD/... card.

So, yes, we love IDs. And we can always provide them ourselves
as label or UUID or so in the filesystem.

But finding an unformatted unlabeled disk is difficult.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/