|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI : EnableACASantosh, The task management functions for iSCSI contain a description the behaviour I am talking about. This was also subject to a long discussion on the list that included the need for ACA behaviour for things like task-set full, busy etc. - not considered for ACA. For the later T10 is handling making ACA behaviour available. Julo Santosh Rao <santoshr@cup.hp.com> on 26/04/2001 20:27:34 Please respond to Santosh Rao <santoshr@cup.hp.com> To: Julian Satran/Haifa/IBM@IBMIL cc: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI : EnableACA Black_David@emc.com wrote: > > > What you are suggesting is that in all cases in which iSCSI would require > > the target to enter ACA (after a LU reset or a target reset) look forward > > in the queue and enter ACA only if it finds a CDB marked NACA? (and that > > includes commands in flight). Julian, I am not suggesting any such thing. ACA is only established when the logical unit completes a command [that had the NACA bit set in its control byte in the CDB] with a CHECK CONDITION status. ACA is not established after a LU Reset or Target Reset. On the contrary, a target reset or LU Reset would clear any existing CAC or ACA. - Santosh > > Ok, so why is iSCSI requiring ACA in addition to Unit > Attention for Clear Task Set, LU Reset and Target Reset? > In all cases, we're dealing with Initiators whose tasks > are cleared as a consequence of another Initiator > issuing the appropriate task management command. > SAM2 only requires Unit Attention. > > --David > > > -----Original Message----- > > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com] > > Sent: Thursday, April 26, 2001 2:22 AM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI : EnableACA > > > > > > > > Santosh, > > > > How about a third confusing response? > > > > We have introduced the EnableACA (per LU) to enable an initiator unwilling > > to use it to disable it at the target for this specific Initiator. > > > > NormACA - the enquiry bit - indicates support for ACA by the target device > > server but is a "read-only" bit. > > > > What you are suggesting is that in all cases in which iSCSI would require > > the target to enter ACA (after a LU reset or a target reset) look forward > > in the queue and enter ACA only if it finds a CDB marked NACA? (and that > > includes commands in flight). > > > > Or to enter ACA only when it finds such a command (sort of "soft ACA")? > > > > Both of them sound wrong and complex. > > > > Julo > > > > Santosh Rao <santoshr@cup.hp.com> on 20/04/2001 22:11:12 > > > > Please respond to Santosh Rao <santoshr@cup.hp.com> > > > > To: ips@ece.cmu.edu > > cc: > > Subject: iSCSI : EnableACA > > > > > > > > > > Julian, > > > > Would the following not satisfy the requirements for dealing with this > > ACA issue : > > > > 1) Initiators determine the target support for ACA through the NACA bit > > in the INQUIRY response. (Assuming iSCSI targets have implemented ACA in > > good faith, this would be supported.) > > > > 2) Initiators set the NACA bit in the CDBs of commands that need strong > > ordering. (This could be a small subset of the I/O traffic to one or > > more LUNs within the session and not required for all the I/Os in that > > session.) > > > > 3) Any exception condition on a SCSI I/O, for which the NACA bit was set > > results in ACA being established. > > Thus, ACA would only be applied if some I/O traffic that required strong > > ordering was affected by the exception condition. > > > > 4) Since the initiator is ACA capable based on its usage of the NACA > > bit, it should also be capable of performing the desired Clear ACA to > > recover from this condition. > > > > Such an approach would only apply ACA and its corresponding recovery > > when some strongly ordered I/O encountered an exception condition, > > rather than applying ACA on a session granularity. > > > > To summarize, the above approach allows : > > - ACA to be turned on/off for a subset of I/Os headed to a LUN > > - ACA based recovery only used where needed. > > - Keeps iSCSI ACA un-aware and rightly so, since this is a property of > > the SCSI ULP. > > - Avoids applying ACA recovery on a session granularity. > > > > What am I missing here (?). Why is an EnableACA needed ? > > > > - Santosh > > > > > > julian_satran@il.ibm.com wrote: > > > > > All references to > > > EnableACA are redundant and should be removed for the following reasons > > > : > > > > > > a) An initiator knows whether a target supports ACA from the NACA bit in > > > the INQUIRY response. When a target indicates support for ACA, the > > > initiator can use it by setting the NACA bit in the CDBs it sends. There > > > is NO need for any sort of negotiation of this behaviour above and > > > beyond what is already provided thru SCSI mechanisms. > > > > > > b) The ACA is a SCSI ULP concept and iSCSI should not be negotiating its > > > use or lack thereof. This is done thru the NACA bit in CDBs. > > > > > > c) (As a side note, the description of EnableACA on pg 127 refers to its > > > presence in the lun control mode page, but it is actually present in the > > > protocol specific port page.) > > > > > > d) ACA is a LUN-level (more an I/O level) control option. It MUST NOT be > > > negotiated on a per-session basis. SCSI allows initiators to request ACA > > > behaviour on a per I/O basis through the use of NACA bit in the CDBs. > > > > > > > +++ We have required ACA to be supported by all new iSCSI targets and > > several > > actions require the target to enter ACA state. > > It was brought to our attention that many initiators will not react > > properly to a > > target entering ACA state (not do the reset). > > The EnableACA bit and key are meant to enable an initiator to control > > this > > iSCSI specific ACA behaviour. This behaviour is related to > > asynchronous > > events and is not controlled by the NACA CDB bit. > > > > ++++ > > - santoshr.vcf > > > > - santoshr.vcf
Home Last updated: Tue Sep 04 01:04:51 2001 6315 messages in chronological order |