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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx> 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@xxxxxxx			      +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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux