On 03/06/2014 09:09, Apollon Oikonomopoulos wrote:
On 14:43 Mon 02 Jun , Nicholas A. Bellinger wrote:
Forwarding to the correct stgt-devel list..
On Fri, 2014-05-30 at 17:38 +0800, lingli tang wrote:
[...]
1. [...] cpu（%user,%sys,%iowait,%idle）,memory(Total，used, free,
buffer, cache), IOPS(read request, write request), Througthput(read
kb, write kb)，
we use tgtd 1.0.47 to export a disk and use iscsiadm to load it.
but the ID_SERIAL of this disk is not the same with scsi_id of export disk.
if we use tgtd 1.0.24 it is the same.
after iscsiadm log in, we check the ID_SERIAL of this disk using
“udevadm info --query=all --path=/block/sdb”：
E: ID_SERIAL_RAW=360000000000000000e001000c00000e0
E: ID_SERIAL=360000000000000000e001000c00000e0
E: ID_SERIAL_SHORT=60000000000000000e001000c00000e0
but with tgtd 1.0.24, it is correct:
E: ID_SERIAL_RAW=1test1-iscsi-iser
E: ID_SERIAL=1test1-iscsi-iser
E: ID_SERIAL_SHORT=test1-iscsi-iser
test environment rhel6.2
We were debugging the exact same thing yesterday, after our persistent
links under /dev stopped working, so here's the short version of the
story:
Commit 6402eb8 added an NAA local designator (WWN) field to tgt's 0x83
VPD (the Device Identification page), and commit 8141d67b further added
an extended WWN. All three identifiers are sent out in tgt's 0x83 VPD,
but udev's scsi_id helper always picks the binary WWN by preference and
uses it as ID_SERIAL, i.e. ignores the ASCII T10 (ID_SERIAL) identifier
present in the VPD. If you use sg_inq from the sg3-utils package you
will get both.
I'm not sure tgt can do much more than make both NAA identifiers
optional, the issue seems to lie with udev at this point.
I added Dennis who is the author of commit 8141d67b -- he made the
following comment: "[...] This is most likely an issue with udev. Most
of the udev tools look at Inquiry VPD 0x83 before looking at VPD 0x80.
With the NAA pages now defined in VPD 0x83, the tools are using that
information instead of VPD 0x80."
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
