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 <h...@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.

This should not hold up Ewan's patches though.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to