lkml.org 
[lkml]   [2013]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: scanning for LUNs
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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2013-04-08 17:41    [W:0.045 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site