Re: [PATCHv2] Add EVPD page 0x83 entries to sysfs
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...HP... 10 61 93 00 08 50 01 0b 90 00 12 1d 8e 61 94 00 04a...P...a... 20 00 00 00 01 61 a3 00 08 50 01 0b 90 00 12 1d 8da...P... 30 63 a8 00 18 6e 61 61 2e 35 30 30 31 30 42 39 30c...naa.50010B90 40 30 30 31 32 31 44 38 44 00 00 00 0000121D8D 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 2003592E05 20 30 30 30 30 30 37 38 33 36 33 32 33 01 03 00 0807836323 30 50 05 07 63 02 41 0c 2c 01 13 00 08 50 05 07 63P..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 01P..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
Re: [PATCHv2] Add EVPD page 0x83 entries to sysfs
On 02/10/2014 08:06 PM, Douglas Gilbert wrote: On 14-02-10 01: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 ...HP... 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 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 2003592E05 20 30 30 30 30 30 37 38 33 36 33 32 33 01 03 00 08 07836323 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 This almost seems like a case where exporting the raw 0x83 data may be better... I have seen corrupted di VPD pages as well. So the order in which you look for designators can be important (and whether you stop on the first error or continue). $ sg_vpd -e -p 0x83 Matching standard VPD pages: di 0x83 Device identification di_asis0x83 Like 'di' but designators ordered as found di_lu 0x83 Device identification, lu only di_port0x83 Device identification, target port only di_target 0x83 Device identification, target device only The difference between --page=di and --page=di_asis is that the first looks for lu, followed by port, followed by target device matches. The --page=di_asis prints out the designators as they are found. Finding and decoding anything beyond a corrupted designator is hit or miss. Yep, true. I'll need to add some boundary checks to the parsing algorithm. 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. I'm guessing that various companies selling target capable chips also provide generic target code for those chips. Then it is up to the OEM to customize that generic code for their devices. Some do that customization more thoroughly than others. Indeed. Some have odd ideas what can be put in there. But nevertheless, the page format is reasonably simple, so adding boundary checks isn't a problem. And if vendors do not adhere to the spec that's tough, but nothing we should code for. 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
Re: [PATCHv2] Add EVPD page 0x83 entries to sysfs
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
Re: [PATCHv2] Add EVPD page 0x83 entries to sysfs
On 02/10/2014 03:15 PM, Christoph Hellwig wrote:
On Mon, Feb 10, 2014 at 12:11:39PM +0100, Hannes Reinecke wrote:
+int vpd_len = 255;
+unsigned char *buffer;
+retry:
+buffer = kmalloc(vpd_len, GFP_KERNEL);
+if (!buffer)
+return;
+
+ret = scsi_get_vpd_page(sdev, 0x83, buffer, vpd_len);
+if (ret) {
+kfree(buffer);
+return;
+}
+
+vpd_len = (buffer[2] 8) + buffer[3];
+if (vpd_len 255) {
+kfree(buffer);
+goto retry;
Won't this create an infinite loop if the VPD is longer than 255 bytes?
Hmm. Sort of.
Gnaa.
Will be redoing the patch.
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
Re: [PATCHv2] Add EVPD page 0x83 entries to sysfs
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...HP... 10 61 93 00 08 50 01 0b 90 00 12 1d 8e 61 94 00 04a...P...a... 20 00 00 00 01 61 a3 00 08 50 01 0b 90 00 12 1d 8da...P... 30 63 a8 00 18 6e 61 61 2e 35 30 30 31 30 42 39 30c...naa.50010B90 40 30 30 31 32 31 44 38 44 00 00 00 0000121D8D 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 2003592E05 20 30 30 30 30 30 37 38 33 36 33 32 33 01 03 00 0807836323 30 50 05 07 63 02 41 0c 2c 01 13 00 08 50 05 07 63P..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 01P..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 This almost seems like a case where exporting the raw 0x83 data may be better... 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 IBM devices are nice in that they export a T10 Vendor ID with the man/model/serial in 0x83, but that is not common in my experience. For example (old T10k) VPD INQUIRY, page code=0x83: 00 01 83 00 20 01 03 00 08 50 01 04 f0 00 93 ac f6... P... 10 01 13 00 08 50 01 04 f0 00 93 ac f7 01 14 00 04P... 20 00 00 00 01 -- 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
