Queuing and ACA

Gerry_Houlder at notes.seagate.com Gerry_Houlder at notes.seagate.com
Thu May 7 09:59:32 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Gerry_Houlder at notes.seagate.com
*
>Joe asks:
>
>The implementation issue I'm facing is that I have two places I apparently
>need to reject a command: prior to queuing, and after dequeuing. As I'm
>understanding the standards, there should be only two cases where an
>ordinary command should be rejected prior to queuing (which has the side
>effect of potentially completing these commands out-of-order) -- with BUSY
>status if the
>queue itself is simply full, and can't accept another command of any sort;
>and with ACA STATUS if NACA is in effect, and the queue is frozen, and
this
>command is not an ACA-queue command from the faulting initiator.
>
>Is this correct?
If the queue is full, the proper status response is QUEUE FULL status. If
there is an ACA condition and the incoming command doesn't have ACA
attribute or isn't from the faulting initiator, the proper status response
is ACA ACTIVE status. If NACA bit was zero in the faulting command (this
technically creates a CA {Contingent Allegiance} condition instead of ACA),
the proper status response to other initiators is BUSY status (this is a
carry-over from SCSI-2 rules).

>I still do not quite understanding the underlying purpose of the ACA
ACTIVE
>status, as opposed to simply letting new commands pile up in the blocked
>queue, or bouncing them with a simple BUSY status, since the initiator
>recovery action for ACA ACTIVE is exactly the same as for BUSY -- try
again
>later.
The ACA ACTIVE status was created as a "short busy" status, indicating the
condition preventing the acceptance of new commands should go away quickly
(within a few seconds or less). Most initiators don't like to see BUSY
status because it implies a long time (for tapes, this could be several
minutes) can occur before more commands will be accepted. You are correct
that ACA ACTIVE and BUSY status both require the initiator to resend the
command, the difference is in how long the initiator should wait before
retrying or maybe how long to wait for that status to go away before
presuming the target may be broken.

Letting commands pile up in a blocked queue can be counter productive. The
blocked commands may end up timing out because they took too long to
execute (due to the extra delay to take care of the ACA condition and
executing the commands ahead of them in the queue). Also, depending on what
error caused the ACA condition, the initiator may want the target to ABORT
some or all commands received after the ACA condition. This behavior is not
usually needed with disk devices, but of often required for tape devices.


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list