X3T9.2/90-062 Rev 3 July 5, 1990 To: X3T9.2 Committee From: John Lohmeyer, NCR Principal Member of X3T9.2 Subject: Initiator Control of Reselection Order Revision 0: This proposal mostly identified the need for initiator control of reselection order in disk arrays based on SCSI disk drives and suggested a method using two new messages. The proposal was assigned to the May SCSI working group. Revision 1: This revision adds greater definition of the two proposed messages. I have based this proposal on the SCSI-2 document, but please note that this is a SCSI-3 proposal. I have also change the names of the messages: I now call the CONTINUE message "CONTINUE I/O PROCESS" and the DO NOT CALL ME message is now called "INITIATOR RECONNECTION REQUEST" -- not as short and sweet, but more suitable for a standard. This revision also adds the Ireconn bit to the standard INQUIRY data so that initiators can determine whether a target supports initiator reconnections. Revision 2: This revision includes the changes requested by the Providence Working Group. The "INITIATOR RECONNECTION REQUEST" message has yet another name: "TARGET DATA RECONNECTION DISABLE" and a slightly changed function. The "ireconn" bit was also renamed "ReconDis" to match the new message name. Revision 3: X3T9.2 accepted revision 2 with some minor changes for SCSI-3 at the June 1990 plenary meeting. The issue of whether TDRD messages should block data transfer on subsequent connections was assigned to the July working group. This revision includes the minor changes accepted in June 1990 plus proposes specific rules for the TTD message (Yes, I changed the name again) to block data transfers on subsequent connections. This later portion was not covered in the motion accepting revision 2. This document shows additions to SCSI-2 in italics. There are no deletions. Underscore is used to highlight changes from Rev 2. Please also see Tom Wicklund's paper (X3T9.2/90-71) for more information about the SCSI disk array problem that this proposal addresses. Table 5-2: Message Codes ============================================================================== Code Support Message Name Direction Negate ATN Init Targ Before last ACK ------------------------------------------------------------------------------ 06h O M ABORT Out Yes 0Dh O O ABORT TAG (Note 1) Out Yes 0Ch O M BUS DEVICE RESET Out Yes 0Eh O O CLEAR QUEUE (Note 1) Out Yes 00h M M COMMAND COMPLETE In --- 12h O O CONTINUE I/O PROCESS Out Yes 04h O O DISCONNECT In --- 04h O O DISCONNECT Out Yes 80h+ M O IDENTIFY In --- 80h+ M M IDENTIFY Out No 23h O O IGNORE WIDE RESIDUE (Two Bytes) In --- 0Fh O O INITIATE RECOVERY In --- 0Fh O O INITIATE RECOVERY (Note 2) Out Yes 05h M M INITIATOR DETECTED ERROR Out Yes 0Ah O O LINKED COMMAND COMPLETE In --- 0Bh O O LINKED COMMAND COMPLETE (WITH FLAG) In --- 09h M M MESSAGE PARITY ERROR Out Yes 07h M M MESSAGE REJECT In Out Yes *** O O MODIFY DATA POINTER In --- 08h M M NO OPERATION Out Yes Queue Tag Messages (Two Bytes) 21h O O HEAD OF QUEUE TAG Out No 22h O O ORDERED QUEUE TAG Out No 20h O O SIMPLE QUEUE TAG In Out No 10h O O RELEASE RECOVERY Out Yes 03h O O RESTORE POINTERS In --- 02h O O SAVE DATA POINTER In --- *** O O SYNCHRONOUS DATA TRANSFER REQUEST In Out Yes 13h O O TARGET TRANSFER DISABLE Out Yes 11h O O TERMINATE I/O PROCESS Out Yes *** O O WIDE DATA TRANSFER REQUEST In Out Yes 14h - 1Fh Reserved 24h - 2FH Reserved for two-byte messages 30h - 7Fh Reserved ============================================================================== Key: M = Mandatory support, O = Optional support. In = Target to initiator, Out = Initiator to target. Yes = Initiator shall negate ATN before last ACK of message. No = Initiator may or may not negate ACK before last ACK of message. (see attention condition, 5.2.1.) --- = Not Applicable *** = Extended message (see Tables 5-3 and 5-4) 80h+ = Codes 80h through FFh are used for IDENTIFY messages (see Table 5-5). NOTES: (1) The ABORT TAG and CLEAR QUEUE messages are required if tagged queuing is implemented. (2) Outbound INITIATE RECOVERY messages are only valid during the asynchronous event notification protocol. 5.6._. CONTINUE I/O PROCESS {Entire message is new} The CONTINUE I/O PROCESS message is sent from the initiator to the target to reconnect to an I/O process. This message shall be sent in the same MESSAGE OUT phase as the IDENTIFY message. IMPLEMENTORS NOTE: Thus the MESSAGE OUT phase following SELECTION phase consists of the IDENTIFY, queue tag (if any), and CONTINUE I/O PROCESS messages. The purpose of the CONTINUE I/O PROCESS message is to distinguish a valid initiator reconnection from an incorrect initiator reconnection (see 6.5.2). If the target expects a significant delay before it will be ready to continue processing the reconnected I/O PROCESS, it may attempt to free the SCSI bus by sending a DISCONNECT message to the initiator. The initiator may reject the disconnection attempt by responding with MESSAGE REJECT message. If the initiator sends this message on an initial connection (i.e., there is no I/O process for the nexus), the target shall go to BUS FREE phase. Initiators should avoid sending this message to targets which have not implemented this message. Such targets may not respond as described in this section. An initiator can determine whether a target implements this message by examining the TranDis bit in the standard INQUIRY data (see 7.2.5.1). 5.6._. TARGET TRANSFER DISABLE {Entire message is new} The TARGET TRANSFER DISABLE (TTD) is sent from an initiator to a target to request that subsequent reconnections for data transfer on the I/O process be done by the initiator instead of the target. The target may reconnect for other purposes, but shall not enter a data phase on a target reconnection. SCSI devices that implement this message shall also implement the CONTINUE I/O PROCESS message. This message is normally shall be sent as the last message of the first MESSAGE OUT phase of a connection. The target may continue the I/O process, including any DATA OUT phases on the initial connection, until the target would normally disconnect, but the target shall not reconnect to transfer data. That is, the target shall not enter a DATA IN phase on the current connection and the target shall not enter any data phase on any subsequent target reconnection for the I/O process. The target shall not enter a DATA OUT phase on the current connection if it is not the initial connection. When the target is ready to transfer data for a disconnected I/O process for which a TTD message has been sent, the target shall reconnect to the initiator for the I/O process, send a DISCONNECT message, and, if the initiator does not respond with a MESSAGE REJECT message, go to BUS FREE phase. This connection serves to notify the initiator that the I/O process is ready for data transfer. If the initiator rejects the DISCONNECT message, the target may enter a data phase; otherwise, the initiator may reconnect to the I/O process as described in the CONTINUE I/O PROCESS message (see 5.6._) to do the data transfer. IMPLEMENTORS NOTE: The above target reconnection has a single MESSAGE IN phase consisting of the IDENTIFY, SIMPLE QUEUE TAG (if it is an I_T_L_Q nexus), and DISCONNECT messages. Initiators should avoid sending the TTD message to targets which have not implemented this message. Such targets may not respond as described in this section. An initiator can determine whether a target implements this message by examining the TranDis bit in the standard INQUIRY data (see 7.2.5.1). 6.5.2. Incorrect Initiator Connection An incorrect initiator connection occurs on a reconnection if: (1) an initiator attempts to reconnect to an I/O process, and (2) a soft reset condition has not occurred, and (3) the initiator does not send an ABORT, ABORT TAG, BUS DEVICE RESET, CLEAR QUEUE, CONTINUE I/O PROCESS, or TERMINATE I/O PROCESS message during the same MESSAGE OUT phase as the IDENTIFY message. An incorrect initiator connection also occurs on an initial connection when an initiator: (1) attempts to establish an I_T_L_Q nexus when an I_T_L nexus already exists from a previous connection, or (2) attempts to establish an I_T_L nexus when an I_T_L_Q nexus already exists unless there is a contingent allegiance or extended contingent allegiance condition present for the logical unit or target routine. A target that detects an incorrect initiator connection shall abort all I/O processes for the initiator on the logical unit or target routine and shall return CHECK CONDITION status. The sense key shall be set to ABORTED COMMAND and the additional sense code shall be set to OVERLAPPED COMMANDS ATTEMPTED. If an initiator reconnects to an I/O process and a soft reset condition has occurred, the target shall meet the requirements of 5.2.2.2. IMPLEMENTORS NOTES: (1) An incorrect initiator connection may be indicative of a serious error and, if not detected, could result in an I/O process operating with a wrong set of pointers. This is considered a catastrophic failure on the part of the initiator. Therefore, vendor-specific error recovery procedures may be required to guarantee the data integrity on the medium. The target may return additional sense data to aid in this error recovery procedure (e.g., sequential-access devices may return the residue of blocks remaining to be written or read at the time the second command was received). (2) Some targets may not detect an incorrect initiator connection until after the command descriptor block has been received. The standard INQUIRY data format is shown in Table 7-15. Table 7-15: Standard INQUIRY Data Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Peripheral Qualifier | Peripheral Device Type | -----|-----------------------------------------------------------------------| 1 | RMB | Device-Type Modifier | -----|-----------------------------------------------------------------------| 2 | ISO Version | ECMA Version | ANSI-Approved Version | -----|-----------------------------------------------------------------------| 3 | AENC | TrmIOP | Reserved | Response Data Format | -----|-----------------------------------------------------------------------| 4 | Additional Length (n-4) | -----|-----------------------------------------------------------------------| 5 | Reserved | -----|-----------------------------------------------------------------------| 6 | Reserved | -----|-----------------------------------------------------------------------| 7 | RelAdr | WBus32 | WBus16 | Sync | Linked |TranDis | CmdQue | SftRe | -----|-+---------------------------------------------------------------------| 8 | (MSB) | - - -|- - Vendor Identification - -| 15 | (LSB) | -----|-+---------------------------------------------------------------------| 16 | (MSB) | - - -|- - Product Identification - -| 31 | (LSB) | -----|-+---------------------------------------------------------------------| 32 | (MSB) | - - -|- - Product Revision Level - -| 35 | (LSB) | -----|-+---------------------------------------------------------------------| 36 | | - - -|- - Vendor Specific - -| 55 | | -----|-+---------------------------------------------------------------------| 56 | | - - -|- - Reserved - -| 95 | | ============================================================================== | Vendor-Specific Parameters | ============================================================================== 96 to| Vendor-Specific | n | Parameter Bytes | ============================================================================== A transfer disable (TranDis) bit of one indicates that the device supports the CONTINUE I/O PROCESS and TARGET TRANSFER DISABLE messages for this logical unit. A TransDis bit of zero indicates that the device does not support one or both of these messages (see 5.6).