[stgt] [RFC PATCH 0/2] Return NAA VPD descriptor, expected by Win initiator

[Doug Clow]

Hello Alexander,

I've created two volumes and they have the following VPD Page 83h Identifiers:

3000000200000002 and
3000000300000003

I'm guessing these ids are built off the target number and the LUN.  Windows seems to accept these disks now, but I'm running into a new problem.  This isn't VPD related if anyone else whose used STGT with Windows can chime in.  

I'm not able to format the disks once mounted in Windows.  I tried reinstalling the scsi-target-utils from yum and the problem persists so I don't think its related to this patch.  Unfortunately there isn't a huge amount of error messages generated.  If I try a quick format, it fails instantly.  If I do a full format, it fills up the bar to 100% and then errors at the very end.  In the Linux side the syslog message is:

May 13 13:13:37 iscsi2 tgtd: conn_close(103) connection closed, 0xb8dfe8 1
May 13 13:13:37 iscsi2 tgtd: conn_close(109) sesson 0xb922e0 1

and in Windows the error is:

A connection to the target was lost, but Initiator successfully reconnected to the target. Dump data contains the target name.

So it seems like the connection is resetting at the end of the format operation.  Any ideas on where I could investigate?

Thanks,
Doug



On May 10, 2013, at 11:07 AM, nezhinsky at gmail.com wrote:

> From: Alexander Nezhinsky <nezhinsky at gmail.com>
> 
> 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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html