ACA handling for "temporary initiators"

Gerry Houlder Gerry_Houlder at
Fri Jun 10 15:27:09 PDT 1994

This scenario was created in the context of XDWRITE command (from my XOR drive
command proposal, X3T10/94-111, that was passed out but not discussed at the
May SCSI Working Group meeting) but the same situation can occur on a COPY
command (which also can result in a temporary inititor). The problem is as
1) Initiator A sends a third party XDWRITE command to device B. The ACA bit is
set in the command bytes.
2) Device B sends an XPWRITE command to device C (in the course of the XDWRITE
operation) that ends with CHECK status. I presume the ACA bit was set in the
command bytes of the XPWRITE command also. This results in an ACA "allegiance"
|from device C to device B.
3) Device B sends REQUEST SENSE to device C to retrieve the sense bytes (or
receives the sense bytes as part of an autosense operation). Device B ends the
XDWRITE command with CHECK status (which results in an ACA "allegiance" from
device B to initiator A) and returns sense data describing the fault on the
third party drive (either as part of auto sense operation or inresponse to a
REQUEST SENSE from initiator A).
4) Initiator A now has sense data describing the problem on device C, but
cannot act to clear the problem because only device B can send commands (with
ACA tag, of course) to device C. How can we solve this???
A) My preferred method:
 Change the ACA tag rules so that the device can accept (and execute) an ACA
tag command from any initiator when the device is in the ACA state. This allows
the real initiator (which presumably if more able to correctly resolve the
error) to access the erroring device directly, with no other special operations
The drawback to this method is that the system must assume all initiators are
"well behaved" in that they will not issue an ACA tag command to a device that
returned ACA ACTIVE status unless that initiator received a previous CHECK
CONDITION status for a command involving that drive. An initiator that knows
about that device's failure should properly resolve the error and send a CLEAR
ACA message (or packet). It also means changes to SAM to allow this behavior.
B) The "transfer ACA" method:
Create a means for device B to transfer ACA allegiance to third party device A.
Device B would have to send a transfer ACA (message? packet? command?) that
would provide the address of device A. This would transfer the allegiance to
the device that is expected to clean up the error without letting any other
device have access to device C.
This works, but involves a lot more changes to SAM and to the protocol
documents to describe such a structure.
I hope everyone gives this some thought and lets me know their preference on
this. I will be giving a presentation on the XOR drive commands at the RAID
study group meeting at Hotel Sofitel in Bloomington, MN June 21 (during the
X3T11 meeting week), so this would be a good time for this discussion. I think
this must be resolved before SAM is finalized.
Gerry Houlder -- Gerry_Houlder at
Seagate Technology   -   920 Disc Drive   -   Scotts Valley, CA 95066 USA
Main Phone 408-438-6550   -   Email Problems postmaster at
Technical Support: BBS 408-438-8771  Fax 408-438-8137  Voice 408-438-8222  

### OGATE Version 8 message trace and attachment information:
### MsgFileName: m:\mgate\outbound\98.MSG
### Org Date:    06-09-94 04:05:55 PM
### From:        Gerry Houlder at SEAGATE
### To:          scsi @ WichitaKS.NCR.COM @ internet
### Subject:     ACA handling for "temporary initiators"
### Attachments: none

More information about the T10 mailing list