> On May 3, 2013, at 4:05 AM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxx> wrote:
>> With tgtadm, you can do something like:
>> # tgtadm --mode logicalunit --op update --tid 1 --lun 1 --params scsi_id=your_id
On Sat, May 4, 2013 at 1:22 AM, Doug Clow <doug.clow@xxxxxxxxxxx> wrote:
> Thanks, I gave it a shot but it looks like the VPD is something different than scsi_id. If I set the scsi_id it still shows up as <Unknown> for the VPD.
> If I mount a SUN COMSTAR target to this Windows machine, the VPD Page 83h Identifier is a 32 character hex number, basically a UUID.
Doug,
It's not that VPD is "different" from scsi_id, but rather there are
many possible formats for the device descriptors
returned thru 0x83 VPD page, multiple types may be returned and some
of them may be preferred by specific
initiators.
A quick test shows that tgtd returns only one type (T10 vendor id):
$ sudo sg_inq --vpd --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
So the "scsi_id" default 00010001 value is used as vendor specific ID
If i send INQUIRY to a local hard drive i see 3 descriptors (vendor
specific, T10 vendor ID, and NAA):
$ sudo sg_inq --vpd --page=0x83 /dev/sg1
VPD INQUIRY: Device Identification page
Designation descriptor number 1, descriptor length: 24
designator_type: vendor specific [0x0], code_set: ASCII
associated with the addressed logical unit
vendor specific: GEA534RV0YX2LA
Designation descriptor number 2, descriptor length: 72
designator_type: T10 vendor identification, code_set: ASCII
associated with the addressed logical unit
vendor id: ATA
vendor specific: Hitachi HDP725050GLA360
GEA534RV0YX2LA
Designation descriptor number 3, descriptor length: 12
designator_type: NAA, code_set: Binary
associated with the addressed logical unit
NAA 5, IEEE Company_id: 0xcca
Vendor Specific Identifier: 0x359cd982f
[0x5000cca359cd982f]
So the T10 one returned by tgtd looks just as valid as the stock HD's one.
I also looked up SPC spec that defines the format and checked hexdump
of the output - it looks ok.
I don't have scst installed currently, but its source code
(you can check scst/src/dev_handlers/scst_vdisk.c:2150, vdisk_exec_inquiry())
shows it reports 3 descriptors: T10 Vendor ID, Relative target port
identifier, and IEEE Id
So it remains unclear which "32 character hex number, basically a
UUID" reported by scst
is recognized by Windows as valid. If it is T10 Vendor ID, then it
does not matter if it is 32 char or
less, as the descriptor is by definition vendor-defined.
Perhaps Windows expects another kind of descriptor?
Could you mount the same target your Windows is happy about from Linux
and run sg_inq?
$ sudo sg_inq --vpd --page=0x83 /dev/sg<X>
where sg<X> represents your device.
Then we shall see which of the descriptors appears on Windows, and
this may help to pinpoint
the problem. If we know that Windows expects another descriptor type,
it is not too hard to add
it to VPD page in tgt.
Alexander
--
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
