Re: scanning for LUNs

[Hannes Reinecke <hare@suse.de>]

On 04/04/2013 07:12 PM, KY Srinivasan wrote:
> 
> 
>> -----Original Message-----
>> From: James Bottomley [mailto:jbottomley@parallels.com]
>> Sent: Thursday, April 04, 2013 11:15 AM
>> To: KY Srinivasan
>> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
>> devel@linuxdriverproject.org; ohering@suse.com; hch@infradead.org; linux-
>> scsi@vger.kernel.org
>> Subject: Re: scanning for LUNs
>>
>> On Thu, 2013-04-04 at 08:12 -0700, K. Y. Srinivasan wrote:
>>> Here is the code snippet for scanning LUNS (drivers/scsi/scsi_scan.c in function
>>> __scsi_scan_target()):
>>>
>>>         /*
>>>          * Scan LUN 0, if there is some response, scan further. Ideally, we
>>>          * would not configure LUN 0 until all LUNs are scanned.
>>>          */
>>>         res = scsi_probe_and_add_lun(starget, 0, &bflags, NULL, rescan, NULL);
>>>         if (res == SCSI_SCAN_LUN_PRESENT || res ==
>> SCSI_SCAN_TARGET_PRESENT) {
>>>                 if (scsi_report_lun_scan(starget, bflags, rescan) != 0)
>>>
>>>
>>> So, if we don't get a response while scanning LUN0, we will not use
>>> scsi_report_lun_scan().
>>> On Hyper-V, the scsi emulation on the host does not treat LUN0 as
>>> anything special and we
>>> could have situations where the only device under a scsi controller is
>>> at a location other than 0
>>> or 1. In this case the standard LUN scanning code in Linux fails to
>>> detect this device. Is this
>>> behaviour expected? Why is LUN0 treated differently here. Looking at
>>> the scsi spec, I am not sure
>>> if this is what is specified. Any help/guidance will be greatly
>>> appreciated.
>>
>> Why don't you describe the problem.  We can't scan randomly a bunch of
>> LUNs hoping for a response (the space is 10^19).  SAM thinks you use
>> LUNW for this, but that's not well supported.  We can't annoy USB
>> devices by probing with REPORT LUNS, so conventionally most arrays
>> return something for LUN0 even if they don't actually have one (That's
>> what the peripheral qualifier codes are supposed to be about).  We
>> translate PQ1 and PQ2 to SCSI_SCAN_TARGET_PRESENT, which means no LUN,
>> but there is a target to scan here.
>>
>> If you're sending back an error to an INQUIRY to LUN0, then you're out
>> of spec.  The SCSI standards say:
>>
>>         SPC3 6.4.1: In response to an INQUIRY command received by an
>>         incorrect logical unit, the SCSI target device shall return the
>>         INQUIRY data with the peripheral qualifier set to the value
>>         defined in 6.4.2. The INQUIRY command shall return CHECK
>>         CONDITION status only when the device server is unable to return
>>         the requested INQUIRY data
> 
> Thanks James. I will further investigate the issue on our platform.
> 
Or check if you can use W_LUN for scanning.
I've done a patchset for this (check the mailing list).

Using W_LUN is precisely for this type of setup.

(And would provide me with another scenario for using W_LUNs :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html