Error Recovery in ATA Queui

Jim McGrath jmcgrath at
Wed Oct 12 09:27:34 PDT 1994

                      Subject:                              Time:  9:11 AM
  OFFICE MEMO         Error Recovery in ATA Queuing         Date:  10/12/94

I want to get input for my queuing proposal on error recovery in an
ATA command queuing environment.  I think we can keep the simplicity
of ATA error recovery, and not jump into SCSI class error recovery,
for three reasons:

1) ATA is a single initiator (host computer) system - weird scenerios
    with multiple initiators cannot occur in ATA
2) my proposal only supports SIMPLE queue tags.  HEAD OF QUEUE has
    been shown to be of little to no practical use in SCSI; similarly
    ORDERED is of very low performance.  In both cases the recommended
    procedure is to let the drive queue go to zero and then issue the HEAD
    QUEUE or ORDERED command.    New commands are not issued until
    that one completes.  Based on my SCSI experience, this will produce 
    almost as high a level of performance for those few times these tags
    are used, but greatly simplify the implementations (all in keeping
    with the spirit of ATA vs SCSI).
3) we have learned a lot from SCSI, and I would advocate that ATA follow
    the 80/20 rule and leave out things of marginal usefulness.

Given this, error handling might be very simple - no CA or ACA condition
is needed.  We have a ready made ABORT COMMAND function (just send
the command/queue tag combination again to abort that command).  Do
we need any more?

Specifically, on an error at the device my recommendation would be to
allow the device to continue functioning - there is no freezing of the
queue.  Afterall, any command (and associated data) already queued
at the drive could have been executed at any time, so the very concept
of freezing the queue makes no sense (as we found out in SCSI-3).  If,
based on an error report, a host wishes to cancel a queued command
rather than completing it (e.g. cancel a write where the command has
been sent, but not all of the write data), then you abort the command.
You can loop and do that for all the command if you want to clear the
drive queue.

In sum, the SCSI features lacking are:
    no ability to restrict reordering of commands in the device queue
    no freezing of queue on error
    no automatic abort of commands at the device on error
    no CLEAR QUEUE or ABORT (only ABORT TAG for a specific command)
    no CA or ACA

One thing you do get in ATA over SCSI is:
    actual size of the device queue (since it is dedicated to a single host)

Are people OK with this?  Specifically, can system software people
compensate for these differences in such a way as to minimize the
differences between supporting SCSI and ATA command queueing?
If not, why not?


More information about the T10 mailing list