From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling Date: Thu, 24 Jan 2013 16:15:34 +0100 Message-ID: <51015016.5050309@suse.de> References: <1358526434-1173-1-git-send-email-emilne@redhat.com> <51011D2E.305@suse.de> <51014A7B.2060806@suse.de> <51014C84.4000906@cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from cantor2.suse.de ([195.135.220.15]:46431 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753642Ab3AXPPg (ORCPT ); Thu, 24 Jan 2013 10:15:36 -0500 In-Reply-To: <51014C84.4000906@cs.wisc.edu> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Mike Christie Cc: Bart Van Assche , "Ewan D. Milne" , linux-scsi@vger.kernel.org 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 wro= te: >>>> As for AEN, does iSCSI _do_ AEN? I thought it got removed ... >>>> >>>> If it does, though, it should schedule an event on its own wheneve= r >>>> 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 tha= t >>> the LUN list has been changed ? Some FC SAN systems send a LIP afte= r 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 s= ense >>> data in case a SAN user first removes all LUNs and after that chang= e >>> adds one or more LUNs. >>> >> The official way is indeed via UAs; most storage arrays (Hello, NetA= pp!) >> provide a default LUN0 which is always visible. >> Up to the point that some even refuse to add 'normal' disk LUNs to L= UN0. >> 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= =2E >> > > In SAM5 there is that QUERY ASYNCHRONOUS EVENT TMF. Could we send tha= t > periodically to lun0/well-knwon-lun if the transport supports it (isc= si > 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 i= t > (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 --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: J. Hawn, J. Guild, F. Imend=F6rffer, HRB 16746 (AG N=FCrnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html