On 16/08/2011 13:08, Martin Svec wrote:
Dne 16.8.2011 11:40, Martin Svec napsal(a):
Dne 16.8.2011 10:01, Andy Shevchenko napsal(a):
On Mon, 2011-08-15 at 18:55 +0200, Martin Svec wrote:
Hello,
Patch e270af8b3c3d6ff3dddc29667df69b691cc517c0
("target: remove custom hex2bin() implementation") causes that for the
same serial number, NAA reported in VPD 0x83 is different than NAA
before this patch. Which in turn confuses iSCSI storage clients like
VMware ESXi etc. after upgrade to the lastest LIO target code.
Before patch:
Device Identification VPD page:
Addressed logical unit:
designator type: NAA, code set: Binary
0x600140535a4c2c4daa90dd591dc453dd
designator type: T10 vendor identification, code set: ASCII
vendor id: LIO-ORG
vendor specific: IBLOCK:35a4c2c4-aa90-d591-c453-d8a60ff00000
After patch:
Device Identification VPD page:
Addressed logical unit:
designator type: NAA, code set: Binary
0x600140535a4c2c3faa90fd590fc453fd
designator type: T10 vendor identification, code set: ASCII
vendor id: LIO-ORG
vendor specific: IBLOCK:35a4c2c4-aa90-d591-c453-d8a60ff00000
I'm not sure which NAA should be the "right" one but the patch
definitely breaks NAA compatibility with previous LIO 4.1 code.
Reverting the patch fixes the problem for me.
Thanks for pointing to this. Brief look at the code shows the
difference
in handling of the improper hex characters:
in case of old code: (X - '0'& 0x0f)
in case of new code: -1 => 0xff
Thus, '-' character is interpreted in the other way. I have no idea how
thing should be converted properly, but it seems for me the '-' signs
should be skipped at all. So, by my opinion, the old code produces
wrong
serial.
I agree that the '-' signs should be skipped at all because both the
old and the new code relies on error-handling behavior of hex-to-bin
converters. It also means that there can be the same NAA for two
different serial numbers which can lead to subtle bugs. Nicholas and
others, wouldn't be better to keep t10_wwn.unit_serial without the
'-' signs? Otherwise, target_emulate_evpd_83() should be fixed to
generate NAAs which will _always_ depend on the _whole_ serial number
only.
Well, it seems to me that there are no format restrictions for
unit_serial in target_core_dev_wwn_store_attr_vpd_unit_serial()
configfs code. Does that mean that wwn unit serial can contain an
arbitrary string? If so, wouldn't be better to generate NAAs using
some kind of hash function instead of hex2bin?
Using a hash function might be quite handy to convert an LVM volume
"UUID" into a NAA/WWN. They look like this:
cNI9Wa-ndUS-lqqe-jKyO-00Vn-NHXe-1lFVa2
HTH,
Chris
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
