RE: iscsi: rev 05 2.5.1 requires ACA support

[Douglas Otis <dotis@sanlight.net>]

David,

In the good old days Tape did not offer ACA as a solution as it did not
queue commands, it depended on buffering.  Oddly neither do drives use ACA
for the reason David mentions.  Tape does use relative addressing within
linked commands where these are defined as being sent over multiple
connections in iSCSI (ye ha).  We have run in circles about placing ACA into
a tape application that never expected to see ACA with Ralph being the
proponent of bit fiddling ACA in and yes it can be done as now required for
those devices bridged over FC as someone pointed out.  I thought the simple
solution would be to not return Sense data within the AutoSense requirement
of iSCSI.  This would force the Tape application to do the right thing and
request Sense specifically upon seeing bad status.  Handing commands
received pending resolution of an error relies on ACA so we seem suck with
it.  Should latency become a greater problem when assuring sequence at the
initiator, there may be a future where a more stringent view would be
desired and ACA is the option that is intended to provide this mechanism.
Who knows, some day someone may actually use ACA.

Doug


> > 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
> ---------------------------------------------------
>
>