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

[Ewan Milne <emilne@redhat.com>]

On Thu, 2013-01-24 at 16:15 +0100, 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.

I believe that multipath is already sending periodic commands to devices
through the different paths, to determine up-to-date path status.
So, in at least some cases, we wouldn't have to do anything else.

> 
> (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