On 2/11/2014 2:32 AM, Hannes Reinecke wrote:
> The problem with page 0x80 is that (per spec) it's vendor-defined. So there
> is no guarantee for it to be unique in any sense. Which makes it rather
> impractical for normal use.
>
> Hence we typically rely on page 0x83 to identify a device, be it for udev
> or multipath.
AFAIK is not vendor defined page, its just not marked as "mandatory" by
T10.
For tape (which I what I thought brought much of this on) it is basically
mandatory. Which is another place where the spec doesn't sync with the real
world.
That is because it is the _ONLY_ vendor neutral method to autoconfigure
tape
libraries. The tape libraries export the drive serial numbers via READ ELEMENT
STATUS, dvcid=1. Which means its the de facto method for backup/media manager
applications. A tape/media changer device that crashes or fails to return useful
0x80 information will have a very short life in the market.
For sure, it would work better than the existing method being used by
udev (for
tape), which fails (per my other posting) because there is often insufficient
information in 0x83 to uniquely identify devices.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
