Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling

[Hannes Reinecke <hare@suse.de>]

On 01/26/2013 07:20 PM, Mike Christie wrote:
> On 01/24/2013 09:15 AM, Hannes Reinecke wrote:
>> On 01/24/2013 04:00 PM, Mike Christie wrote:
>>> On 01/24/2013 07:51 AM, Hannes Reinecke wrote:
>>>> On 01/24/2013 03:38 PM, Bart Van Assche wrote:
>>>>> On Thu, Jan 24, 2013 at 4:38 AM, Hannes Reinecke <hare@suse.de> wrote:
>>>>>> As for AEN, does iSCSI _do_ AEN? I thought it got removed ...
>>>>>>
>>>>>> If it does, though, it should schedule an event on its own whenever
>>>>>> an AER
>>>>>> is received. The same goes for LLDDs with vendor-specific AENs;
>>>>>> thinking of
>>>>>> megaraid_sas here ...
>>>>>
>>>>> Let me ask this another way. SAN users expect that the LUN list at the
>>>>> initiator side gets updated automatically after a SAN configuration
>>>>> change. How should a SAN system communicate to a SCSI initiator that
>>>>> the LUN list has been changed ? Some FC SAN systems send a LIP after a
>>>>> configuration change to force the initiator to rescan LUNs.
>>>>
>>>> And thereby disrupting traffic on _ALL_ LUNs on the loop.
>>>> Really cool idea.
>>>> I know; the one vendor which does _not_ talk to us.
>>>>
>>>>> But how to inform the initiator about a LUN change for other SCSI
>>>>> protocols ?
>>>>> I'm not sure that it is even possible to report such a change via sense
>>>>> data in case a SAN user first removes all LUNs and after that change
>>>>> adds one or more LUNs.
>>>>>
>>>> The official way is indeed via UAs; most storage arrays (Hello, NetApp!)
>>>> provide a default LUN0 which is always visible.
>>>> Up to the point that some even refuse to add 'normal' disk LUNs to LUN0.
>>>> Or have the ominous 'Well-known Address' LUN to handle these kind of
>>>> issues.
>>>>
>>>> Obviously, one needs to send commands to it to even _get_ an UA back.
>>>>
>>>
>>> In SAM5 there is that QUERY ASYNCHRONOUS EVENT TMF. Could we send that
>>> periodically to lun0/well-knwon-lun if the transport supports it (iscsi
>>> will in
>>> http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-06#section-6).
>>> Whatever daemon in userspace handles these other events, could send it
>>> (we just need to add a interface) or we could add kernel code.
>>>
>> Oh, cool.
>> Polling a device to figure out if we should poll it :-)
>>
>> We'd be better off sending TEST UNIT READY to it; then we should
>> be getting UAs regardless on the SAM version in use on the target.
>>
>
> To handle the case where all devices are removed then new ones are
> added, we will not have kernel structs or /dev/sdXs to send TURs to to
> find new ones. Are you thinking we would do something like have the
> kernel create temp structs to send TURs to LUN0/well-known-lun? Or, do
> you think we would have something doing scsi scans (call
> scsi_scan_target or scsi_scan_host) every once in a while?
>
Well, not as such.

Most arrays (eg RDAC, EVA, or EMC) will present you with a separate 
device (like the infamous 'Universal Xport' :-) which will be 
present always, so it can be used for polling in case no targets are 
present.
NetApp and the like are more tricky as they do _not_ present any 
targets per default. So we'd need something here to talk to.
Some kind of 'virtual' LUN0 or somesuch.

Wouldn't this be a grand topic for LSF?

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