Hi Alexander, This is very informative, thanks. The COMSTAR disk that Windows liked was actually a fibre channel device and this Linux machine doesn't have a fibre adapter. But I have an even better idea, I'll make an iSCSI target in Windows and then run the query you showed me and report my findings. Regards, Doug On May 4, 2013, at 7:39 AM, Alexander Nezhinsky <nezhinsky@xxxxxxxxx> wrote: >> 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
