RE: iSCSI 07-95 Comment 3 -Task Management

[Black_David@emc.com]

Bob, that's not completely correct - to be precise, for the
example I gave, there's text in SAM-2 that forbids the response
from the aborted task from being presented to the Initiator
after the Task Abort has completed successfully.  If you want
to suggest that the task should be executed and its response
discarded, I would observe that the result would make task
management much less useful because Task Abort becomes inherently
unreliable (the Task can execute after being successfully 
Aborted).

FWIW, FCP uses a Fibre Channel abort primitive to accomplish
this sort of task abort rather than transmitting the SCSI Task
Abort to the Target and achieves a similar result - there
is no possibility of task execution after a successful Task
Abort - it sounds like this is also in excess of SCSI's
requirements if I understand what you wrote.

The underlying issue here is that SAM-2 assumes a synchronous
transport and hence a bunch of things that can "go wrong"
with iSCSI's asynchronous and parallel transport in the area
of task management simply can't occur in SAM-2's model of
the world - the primary purpose of this restriction is to
preserve SAM-2's model of the world in the area of task
management so that task management behaves as SAM-2 leads
one to expect.

Thanks,
--David

> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Wednesday, September 26, 2001 7:53 PM
> To: 'Black_David@emc.com'; tdineen@redswitch.com; ips@ece.cmu.edu
> Subject: RE: iSCSI 07-95 Comment 3 -Task Management
> 
> 
> David,
> 
> These are restrictions that you have placed on iSCSI that
> are beyond those of SCSI.
> 
> Bob
> 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Wednesday, September 26, 2001 4:03 PM
> > To: tdineen@redswitch.com; ips@ece.cmu.edu
> > Subject: RE: iSCSI 07-95 Comment 3 -Task Management
> > 
> > 
> > An implementation can choose when in time it chooses to
> > execute the task management command, but the effects visible to
> > the Initiator must be as if it was executed in CmdSN order
> > For example, if an Abort Task passes the task that it is
> > supposed to abort on a different connection and the Abort Task
> > has a higher CmdSN, the Target may immediately respond to the
> > Abort Task, but in that case, it MUST NOT execute the
> > "aborted" task when it arrives.  I agree that this could
> > use some further explanation in the draft.
> > 
> > --David
> > 
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > 
> > > -----Original Message-----
> > > From: Thomas Dineen [mailto:tdineen@redswitch.com]
> > > Sent: Tuesday, September 25, 2001 7:58 PM
> > > To: ips@ece.cmu.edu; Thomas Dineen
> > > Subject: iSCSI 07-95 Comment 3
> > > 
> > > 
> > > Gentle People:
> > > 
> > > Section 3.1.5 on P64
> > > 
> > > "Task management commands must be executed
> > > as if all the commands having a CmdSN lower or equal to the task
> > > management CmdSN have been received by the target (i.e., 
> have to be
> > > executed as if received for ordered delivery even when marked for
> > > immediate delivery)."
> > > 
> > > After reading this paragraph over several times I am still having
> > > trouble
> > > understanding what it means. Do you mean execute the command 
> > > immediately
> > > while ignoring the normal order or execute the command in 
> the normal
> > > commandSN order?
> > > 
> > > Thomas Dineen
> > > 
> > 
>