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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
