Error Recovery in ATA Queui
Jim McGrath
jmcgrath at mail.qntm.com
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:
HEAD OF QUEUE, ORDERED tags
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?
Jim
More information about the T10
mailing list