|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: aborting an immediate command with ABORT TASKThe plug-in is meant to avoid having to resend the missing command. This is also the reason for mandating ABORT TASK on the same connection! Julo
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Black_David@emc.com > Sent: Tuesday, September 03, 2002 7:21 PM > To: tonyb@cybernetics.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > > > Tony, > > > > 2) The race between an immediate command finishing normally > > > (causing the target to free the command and forget its > associated ITT) > > > and the initiator aborting it > > That's not correct. In case 2) the ABORT TASK always succeeds no > matter how the race turns out - SAM-2 Section 6.2 says: > > If the logical unit supports this function, a response of > FUNCTION COMPLETE shall indicate that the task was aborted > or was not in the task set. > > The words "or was not in the task set" are the crucial ones. In > case 2), the ABORT TASK always returns FUNCTION COMPLETE, and > there may > or may not be a response from the aborted task prior to that FUNCTION > COMPLETE, but there MUST NOT be one afterwards. I am not really concerned about the response code to the ABORT TASK. My concern is that the initiator may end up plugging a CmdSN hole when it shouldn't. From Section 9.6.1 (draft 15), "...targets must consider the CmdSN received and return the "Function complete" response." I don't have a problem with returning the "Function complete" response. I do have a problem with the target considering the CmdSN received if the initiator intended to abort an immediate command. Tony
Home Last updated: Wed Sep 04 11:18:58 2002 11757 messages in chronological order |