CA_ACA Proposal 97-225r0.DOC

Tom coughlan at
Fri Aug 29 13:56:33 PDT 1997

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* coughlan at (Tom)

I have interspersed comments between excerpts from the proposal.

>... application environments are strongly requesting that SCSI devices
>handle errors in such a 
>way that host systems can be unaware of any errors that are encountered by 
>other host systems. Achievement of this goal places requirements on the 
>device's behavior such as maintaining separate sense data for each host, not 
>freezing the queue for all hosts when one host is in contingent
>allegiance, and 
>not sending BUSY status to a host because another host has encountered
>some type of error condition. This need was discussed at the July T10
>working group meeting and action was assigned to generate this proposal.

I strongly support the goal.  In fact, I think this proposal does not go
far enough in at least one respect.  That is:

>This proposal assumes applications that want no impact 
>in command execution from other initiators will not invoke ordering. This 
>proposal does not include a method to divide ordering on a per initiator

I believe that, as a result of preserving ordering, the CA_ACA proposal is
unnecessarily complex, difficult to implement, and therefore, will result
in systems that are less reliable than they could be.  The last thing we
need are more rules for handling CA and ACA, probably the most complex
aspect of SCSI.  

The CA_ACA proposal allows the device server to act as though each
initiator has a separate task set, except when ordered commands are
issued, and then the device server has to act as though there is just one
command queue.  It would be much more desirable to create an option that
allows a device server to actually implement separate task sets for each
initiator.  This would be much simper to comprehend, and implement, and
more likely to be correct.

There are two reasons I know of that an initiator might use ordered

    1) To enforce ordering among commands it has issued.  

    2) To enforce ordering between its commands and those of other

Item number one above would still function correctly if the device server
had separate task sets per initiator.  In fact, it would work better,
because there wouldn't be any interaction with errors caused by  
other initiators.

The application where number two above has been used is in clusters where
multiple hosts share a storage device simultaneously (no reservations).
In these systems, if one host fails, the other hosts can use an ordered
command to determine when any commands that were queued by the failed host
are done.     

Until recently there was no good alternative to ordered commands for 
achieving this cross-initiator I/O barrier.  Now, however, we have a
better method:  the Persistent Reservation Preempt and Clear service
action.  Persistent Reservation is better than an ordered command for this
purpose because it is more timely, it breaks through CA and reservations,
and it can be used to block subsequent I/O from the unresponsive
initiator.  The only disadvantage of PR is that it is optional, and it is
not clear how widely implemented it will be.  

I'd like to suggest that we change the "CA_ACA" proposal to a simpler,
"multiple task set" proposal.  The expectation (and what you would find in
purchase specs. from cluster vendors) is that devices that implement
multiple task sets will also implement Persistent Reservation.

Isn't this a reasonable trade-off?
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list