RE: iscsi: rev 05 2.5.1 requires ACA support

[Black_David@emc.com]

If that's the case, then the wording that Ralph
pointed out needs to be modified to indicate that
ACA is used only when appropriate.

--David

> -----Original Message-----
> From:	julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com]
> Sent:	Friday, March 16, 2001 2:34 AM
> To:	ips@ece.cmu.edu
> Subject:	RE: iscsi: rev 05 2.5.1 requires ACA support
> 
> 
> 
> We are aware of the support for ACA missing from some drivers.
> The situation is even exacerbated by the fact that certain exceptions that
> are not errors per-se
> will require ACA to be fired to accomodate for commands in flight (like
> reservations, busy, task-set-full).
> 
> However actions at the initiator can be fine-tuned with the NACA bit in
> CDB
> and the ACA atrribute for the task.
> 
> Julo
> 
> Black_David@emc.com on 16/03/2001 03:46:29
> 
> Please respond to Black_David@emc.com
> 
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  RE: iscsi: rev 05 2.5.1 requires ACA support
> 
> 
> 
> 
> > After an error if you have commands in flight you want them all dropped
> > until you specifically reset the ACA and restart the queue (prevent
> things
> > to be executed out of order).
> 
> The T10 folks will have to go after this one in more detail, but Julian's
> above statement is correct *only* if the commands in flight depend on
> the one that caused the error (i.e. executing them out of order will cause
> problems).  This is generally not the case for disks where the usual
> practice is to enforce command execution order dependencies
> (e.g., database write ordering) in the operating system and applications
> by waiting for responses (yes it's possible to do better, but lots of
> existing software doesn't).  The result is that commands in
> flight can be executed in arbitrary order with arbitrary ones of them
> failing without causing further difficulties.  As Ralph has pointed out,
> most hosts do not use ACA for disk-based storage, and if iSCSI
> always does ACA, this will cause nasty integration issues.
> 
> Just to stir the pot further, I believe Fibre Channel provides a negative
> example, because if FC drops a frame (which is not a good idea,
> but can still happen), the FC component that dropped the frame has no
> clue about what ACA is, or how to get the target (which is not the
> same piece of hardware) to enter ACA state.  Both Class 2 and Class 3
> are vulnerable to this.
> 
> Tapes are another matter - do we still have a tape expert on the list?
> 
> I thought where we were headed on ACA was something along the
> lines of:
> - Targets MUST implement.
> - Initiators MAY use.
> - Initiator support for ACA is NOT REQUIRED.
> which would imply a text key for Initiators to tell Targets
> whether ACA behavior is expected.  Did I miss something?
> 
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> 
>