From: Alexander Nezhinsky <nezhinsky@xxxxxxxxx> I have implemented a simple NAA descriptor, returned in addition to SCSI ID. Now Linux returns this info: $ sudo sg_inq --page=0x83 /dev/sg4 VPD INQUIRY: Device Identification page Designation descriptor number 1, descriptor length: 40 designator_type: T10 vendor identification, code_set: ASCII associated with the addressed logical unit vendor id: IET vendor specific: 00010001 Designation descriptor number 2, descriptor length: 12 designator_type: NAA, code_set: Binary associated with the addressed logical unit NAA 3, Locally assigned: [0x3000000100000001] Citing the requirements by MS: "For VPD Page 83, type 2 or type 3 descriptors nust be returned and must be unique for each logical unit." NAA is type 3. It has an option for vendor specific, "locally assigned" descriptor. TYpe 2, EUI descriptor has no such option and requires a certified vendor id. scst returning EUI violates its basic requirements. Perhaps it is swallowed by Win initiator. Anyway, if the "local" NAA works, then it seems the least agressive fake id. I hope it is *not* what was meant by the MS document: "Vendor-specific device identifiers, if present, must use type 0 and follow the specified format, including correct page length; vendor specific identifiers are not a substitute for the mandatory type 2/3 descriptors." vendor specific identifier of type 0 is: "7.7.3.3 Vendor specific designator format If the designator type is 0h (i.e., vendor specific), no assignment authority was used..." Thus i hope that a vendor-specific (localy assigned) within the framework of NAA is ok. Please try to re-run the Windows-based test with the new code. Alexander Nezhinsky (2): spc_inquiry: store evpd flag and page code in local vars; remove redundant if add NAA Locally Assigned designator to 0x83 VPD page usr/spc.c | 46 ++++++++++++++++++++++++++++++++++++---------- usr/tgtd.h | 1 + 2 files changed, 37 insertions(+), 10 deletions(-) -- 1.7.9.6 -- 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