Subject: RE: [Ips] Abort/error handling for task with pending data sequenc e

From: Jane Liu <[email-masked]>
Date: Thu, 19 Feb 2004 17:17:32 -0800

Please see comments below.

>> Hi, 
>> What should the target do when it gets an Abort Task request for a 
>> SCSI write command that has an unterminated data sequence? Is it safe 
>> to assume that the initiator will not send any more data PDUs for the 
>> task to be aborted? 

> No it is not safe. The target should send it's response to TM only after 
> receiving all the data (unsolicited and expected).
> The data may be arriving on a different connection than the TM or may be 
> generate by a different thread at the initiator (there is no guaranteed 
> sequence).

I'm still not very clear on this. What should the target do in the following
scenario:
("I->T CID 0" means "initiator to target on connection with CID 0")

 I->T CID 0: SCSI write command with ITT = X, F-bit = 0
 I->T CID 0: Data-Out with ITT = X, F-bit = 1
 Connection 0 fails after the initiator sends out the Data-Out but before
the target receives it.
 Connection 0 gets logged out. 
 I->T CID 1: Abort Task TM to abort ITT X

Should the target wait for the event [I->T CID 1: Data-Out with ITT = X,
F-bit = 1]? 
It seems that such an event can only occur after a succesful reassignment of
the write command to connection 1. Section 10.5.1 of the spec says that the
TM will "establish a new allegiance for the command to be aborted as well as
abort it" and "the task to be aborted will not have to be retried or
reassigned". I'm not exactly sure what these requirements entail in such a
scenario. 

Again, all help appreciated.  
 
Jane Liu

---

From: Julian Satran <[email-masked]>
Date: Sat, 21 Feb 2004 10:54:38 +0200

Here you can safely terminate without additional wait since the logout 
does the cleaning.
The logout specification is the only one that includes "quiescing" (no 
more data).
The reasoning behind not requiring "no data after abort" it is that for 
regular aborts you don't want necessarily to involve initiator pieces that 
may work in parallel (like a TM arriving at the target on a different 
connection than a TM).

In case of logout you do not have the above issue.

So for regular abort you may have to wait for data.
If you do also a logout then you don't have to wait.

Julo

Jane Liu <[email-masked]> 
20/02/2004 03:17

To
Julian Satran/Haifa/IBM@IBMIL
cc
[email-masked]
Subject
RE: [Ips] Abort/error handling for task with pending data sequenc       e

> generate by a different thread at the initiator (there is no guaranteed 
I'm still not very clear on this. What should the target do in the 
following scenario: 
("I->T CID 0" means "initiator to target on connection with CID 0") 
 I->T CID 0: SCSI write command with ITT = X, F-bit = 0 
 I->T CID 0: Data-Out with ITT = X, F-bit = 1 
 Connection 0 fails after the initiator sends out the Data-Out but before 
the target receives it. 
 Connection 0 gets logged out. 
 I->T CID 1: Abort Task TM to abort ITT X 
Should the target wait for the event [I->T CID 1: Data-Out with ITT = X, 
F-bit = 1]? 
It seems that such an event can only occur after a succesful reassignment 
of the write command to connection 1. Section 10.5.1 of the spec says that 
the TM will "establish a new allegiance for the command to be aborted as 
well as abort it" and "the task to be aborted will not have to be retried 
or reassigned". I'm not exactly sure what these requirements entail in 
such a scenario. 
Again, all help appreciated. 
  
Jane Liu 

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips