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

From: Hannes Reinecke <hare@suse.de>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: Bart Van Assche <bart.vanassche@gmail.com>,
	"Ewan D. Milne" <emilne@redhat.com>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
Date: Thu, 24 Jan 2013 16:15:34 +0100	[thread overview]
Message-ID: <51015016.5050309@suse.de> (raw)
In-Reply-To: <51014C84.4000906@cs.wisc.edu>

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.

(Especially as some target lie about the supported version, so
they might be supporting SAM-5 without telling us ...)

> This should not hold up Ewan's patches though.
>
Correct.

AEN handling discussion is a different story and should be build
on top of Ewans patches.

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