Queuing and ACA

Joseph C. Nemeth jnemeth at concentric.net
Tue May 5 13:39:40 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Joseph C. Nemeth" <jnemeth at concentric.net>
*
I'm going over the whole SCSI-3 queuing process a final time, and I want to
make sure I  understand what is supposed to happen here. The issue has to do
with a fine point of implementation of the queuing process, and how it
affects the order in which commands are completed.

As I understand this, when the NACA condition goes into effect, the command
queue for a device/LUN effectively freezes completely. Dormant tasks remain
dormant. Enabled tasks become blocked, including the current task. New
non-ACA-queue commands sent to the device are immediately bounced without
even being queued, with ACA ACTIVE status. New ACA-queue commands from the
faulting initiator are immediately entered in the enabled state, and since
everything else is dormant or blocked, they execute immediately, effectively
bypassing the queue entirely.

Therefore, the ACA ACTIVE status results (technically) in an out-of-order
completion of commands received before and after NACA goes into effect:
commands received and queued before NACA occurs remain frozen in the queue
until NACA is cleared by the faulting initiator, but commands received after
NACA occurs complete immediately with ACA ACTIVE status.

Is this correct?

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 essentially correct?

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.

Joseph C. Nemeth, Precision Algorithms



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