On 02/10/2014 07:06 PM, Jeremy Linton wrote: > On 2/10/2014 5:11 AM, Hannes Reinecke wrote: >> EVPD page 0x83 is used to uniquely identify the device. So instead of >> having each and every program issue a separate SG_IO call to retrieve this >> information it does make far more sense to display it in sysfs. > > Tested-by: Jeremy Linton <jlin...@tributary.com> > > So, I just ran it in 3.14-rc2. No OOPS, that is good. It even survived > probing a SPC-2 device without a page 0x83. > > I tested it with a fairly narrow set of devices, a couple IBM libraries with > LTO/359x and a VTL. > > I did notice this on an old IBM raid adapter running in the machine > > cat: ident_lun_scsi_name: Invalid argument > > (that came from this device) > sg_inq --page=0x83 --hex /dev/sg2 > VPD INQUIRY, page code=0x83: > 00 00 83 00 48 01 03 00 08 50 01 0b 90 00 12 1d 90 ...H....P....... > 10 61 93 00 08 50 01 0b 90 00 12 1d 8e 61 94 00 04 a...P.......a... > 20 00 00 00 01 61 a3 00 08 50 01 0b 90 00 12 1d 8d ....a...P....... > 30 63 a8 00 18 6e 61 61 2e 35 30 30 31 30 42 39 30 c...naa.50010B90 > 40 30 30 31 32 31 44 38 44 00 00 00 00 00121D8D.... > Yeah, correct. The selection algorithm is a tad flawed. I'll be fixing it up.
> And there may be a couple descriptors missing here and there. For example > 3592E05 is missing the total port count (I think). > > VPD INQUIRY, page code=0x83: > 00 01 83 00 5c 02 01 00 24 49 42 4d 20 20 20 20 20 ...\...$IBM > 10 30 33 35 39 32 45 30 35 20 20 20 20 20 20 20 20 03592E05 > 20 30 30 30 30 30 37 38 33 36 33 32 33 01 03 00 08 000007836323.... > 30 50 05 07 63 02 41 0c 2c 01 13 00 08 50 05 07 63 P..c.A.,....P..c > 40 02 81 0c 2c 01 14 00 04 00 00 00 02 01 23 00 08 ...,.........#.. > 50 50 05 07 63 02 41 0c 2c 01 24 00 04 00 00 00 01 P..c.A.,.$...... > > /sys/class/scsi_tape/nst14/device # ls ident_* > ident_lun_naa ident_lun_t10 ident_port_naa ident_port_relport > ident_target_naa > Well, yes, it does, as the missing ident is this: 01 24 00 04 00 00 00 01 Which decodes as 'Association: Target', 'Designator: Relative target port identifier', and is not defined as per spec (and it doesn't make sense to boot). As you might've seen I've included only the valid/defined association/designator combinations in the patch. > > > > This almost seems like a case where exporting the raw 0x83 data may be > better... > Hmm. I'd rather have the actual strings in sysfs; the whole idea of this patch was to have strings in sysfs which can be read directly. Having a binary blob only requires you to have yet another tool for parsing that data. And for XCOPY we need the descriptor anyway, so at one point we need to parse this. But OTOH there's no reason why we _shouldn't_ export it to sysfs directly. So let's do both. > > Also, as I stated previously, my personal bias is to include the page 0x80 > serial number data for tape devices as well. That seems to be the most > reliable. Mostly because a lot of the VTLs now just give you the same > wwnn/wwpn in 0x83 for multiple LUNs. Meaning you can't uniquely identify the > device over different physical ports. > 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. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
