Subject: RE: [Ips] Receiving a SCSI response after abort task was sent

From: [email-masked]
Date: Mon, 3 Jul 2006 09:54:04 -0400

Erez,
 
> I have a question about aborting tasks: when an initiator sends "abort
task" to the target,
> it is possible that the target will send a SCSI response for the same task
before receiving the
> abort task (I guess that the target won't send a task management response
for the abort task).
 
Yes and (No) in that order.  The "abort task" task management function
is defined to succeed when the task does not exist - the response will
indicate success in this situation.
 
> What should the initiator do with the SCSI response?
 
Process it normally, as it would any other SCSI Response.
 
> Is the host that issued the abort task willing to receive a SCSI response
for that task?
> Is it willing to receive only a task management response for the abort
task?
 
Yes and No in that order, the SCSI response is possible and must be
handled.  There will always be a task management response, independent
of whether the SCSI response is issued.  One important rule is that
the SCSI response cannot occur *after* the task management response.
 
Thanks,
--David
---------------------------------------------------- 
David L. Black, Senior Technologist 
EMC Corporation, 176 South St., Hopkinton, MA  01748 
+1 (508) 293-7953             FAX: +1 (508) 293-7786 
[email-masked]        Mobile: +1 (978) 394-7754 
---------------------------------------------------- 

  _____  

From: Erez Zilber [mailto:[email-masked]] 
Sent: Sunday, July 02, 2006 6:48 AM
To: [email-masked]
Subject: [Ips] Receiving a SCSI response after abort task was sent

Hi,

I have a question about aborting tasks: when an initiator sends "abort task"
to the target, it is possible that the target will send a SCSI response for
the same task before receiving the abort task (I guess that the target won't
send a task management response for the abort task). What should the
initiator do with the SCSI response? Is the host that issued the abort task
willing to receive a SCSI response for that task? Is it willing to receive
only a task management response for the abort task?

This message was also sent to linux-scsi mailing list.

Thanks

-- 

____________________________________________________________

Erez Zilber   |  972-9-971-7689

Software Engineer, Storage Team

Voltaire - The Grid Backbone

 www.voltaire.com <http://www.voltaire.com/> 

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

---

From: "Robert Snively" <[email-masked]>
Date: Mon, 10 Jul 2006 10:53:55 -0700

Eddy,
 
Julian has shown you one example.
 
A second example is in some Fibre Channel environments, where in-order
delivery is optional.  In those cases, the rules say that you shall not
re-use
the fully qualified exchange identifier until a timeout has passed that
guarantees
that all possible responses have either been discarded in the network or
received (and discarded) by the initiator.
 
Of course, any technology may have a target failure that generates a
response for a command that either no longer exists or has never
existed.
That should not confuse anyone and certainly should not bring down an
initiator.  Be forgiving, and accept the unexpected response and discard
it.
You may choose to post a notice to some upper programming level, but
the system should not crash or create operational problems for other
targets.
 
Bob

________________________________

From: Julian Satran [mailto:[email-masked]] 
Sent: Monday, July 10, 2006 9:19 AM
To: Eddy Quicksall
Cc: [email-masked]; [email-masked]; Robert Snively; William
Studenmund
Subject: Re: [Ips] Receiving a SCSI response after abort task was sent

Eddy, 

I don't think was talking about iSCSI (where it should not happen). But
SCSI was defined for a variety of technologies some which do not have
ordered and reliable transport. If you take technologies that have a
"link-by-link" error recovery (such as PCI express) and include some
switches in the "pot" this may definitely happen. So it is wise to be
prepared for it. 

Regards, 
Julo 

"Eddy Quicksall" <[email-masked]> 

09/07/06 13:35 

To
"William Studenmund" <[email-masked]>, "Robert Snively"
<[email-masked]> 
cc
[email-masked], [email-masked] 
Subject
Re: [Ips] Receiving a SCSI response after abort task was sent

Wasn't Bob talking about technologies other than iSCSI? 
  
Bob, are you sure? Do you have an example of such a technology? 
  
I would think it would be dangerous for a technology to allow a SCSI
response to be received after the TMF response has been received for the
same command. My reasoning is that once the initiator has received the
TMF response it can reuse the ITT. In that case if the SCSI response for
the aborted command comes after the TMF response for the same command
but a new command has already used the same ITT, then there would be no
way to determine that the response should be discarded. 
  
Eddy 
----- Original Message ----- 
From: William Studenmund <mailto:[email-masked]>  
To: Robert Snively <mailto:[email-masked]>  
Cc: [email-masked] <mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  
Sent: Wednesday, July 05, 2006 1:47 PM 
Subject: Re: [Ips] Receiving a SCSI response after abort task was sent 

On Jul 3, 2006, at 10:18 AM, Robert Snively wrote: 

With one minor warning, I agree with David. 
  
Warning below: 

> Is the host that issued the abort task willing to receive a SCSI
response for that task? 
task? 

In some technologies and under some conditions, it is hypothetically
possible for a SCSI 
response to appear at an initiator after the task management response.
In such environments, this will 
be detected as a SCSI response for which there is no SCSI request and it
will be discarded. 
Since TCP/IP forces in-order behavior on the SCSI stream, and since the
abort task is 
normally sent through the same stream as the command, this normally may
be ignored 
by iSCSI. 

I don't think this is a concern, because the ABORT TASK MUST be on the
same connection (section 10.5.1, page 131 of RFC 3720) as the command in
question. Thus StatSN numbering for the two is in the same number space.
The SCSI response should have a lower StatSN than the TMF response as
StatSN is the only real way to determine what is "before" or "after",
and we are talking about the case where the task finished "before" the
abort. 

So as the initiator processes StatSN responses, it will see the SCSI
response "before" the TMF response. 

As long as any other iSCSI transport (other than TCP) retains StatSN,
this will work right. 

Take care, 

Bill 

________________________________

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