|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI: abort task & abort task set
Julian,
I like
the proposal made at the IETF. I had two follow up questions
1. For
targets that only support single connection per session, and
do
not
support error recovery, would it be ok to send the status for
the
task
management command without having to wait for the status ack
for
all previously sent statuses?
2. I
have to analyze in more detail, but there is an interesting
case
where
let us say that the status sent prior to the
task
management status suffers from a digest error, or a
connection
failure. The initiator retries the command on another
connection. I
have
not fully figured out the implications of this.
Somesh
Dear all,
On a phone conversation we have agreed to
change the required behaviour along those lines enabling the initiator to drop
all outstanding commands after a
response from a the task management abort/clear-task-set is received.
The iSCSI target will carry the burden for
waiting for all outstanding statuses on all connections to be acknowledged
after receiving the abort confirmation from the SCSI target and sending all
statuses before returning the task management response.
Julo
| "Mallikarjun C."
<cbm@rose.hp.com> Sent
by: owner-ips@ece.cmu.edu
12-03-01 07:53 PM Please respond to cbm
| To:
ips@ece.cmu.edu cc:
Subject: Re: iSCSI: abort task &
abort task set
|
Resolution of this certainly requires an offline discussion - which
we two plan to have. But one comment to make my proposal clear to the
list.
> I propose that the target deliver only the TMF response on
an abort of > an active task on an 'abort task' TMF, and not transmit an
'abort task > set' > TMF response until all the current StatSN's
on all connections (as on > the > completion of "abort task set')
in the session are ack'ed. This ack > may be > solicited by
way of a NOP-IN with valid TTT. > > +++ that may result in an
initiator reusing prematurely an ITT and > being hit by a late arriving
status > for a "former" task - i.e. non-deterministic behavior
+++
That is not possible since as I said above, the 'abort task
set' TMF response is sent only after all StatSN "snapshots" are ack'ed
on all connections. -- Mallikarjun
Mallikarjun
Chadalapaka Networked Storage Architecture Network Storage Solutions
Organization Hewlett-Packard MS 5668 Roseville CA
95747
Julian Satran wrote: > > Mallikarjun, >
> Comments in text - Julo > > PS - I would like also to
point out that we may want to consider a > very simple alternative to
the barrier scheme outlined in 9.4 > - that will require less
cooperation between initiator and will be > simpler to read and
implement. > I will outline such a scheme soon. > >
"Mallikarjun C." > <cbm@rose.hp.com>
To:
"ips" > Sent by: owner-ips@ece.cmu.edu
<ips@ece.cmu.edu> >
cc: > 12/03/2001 01:33 AM
Subject:
iSCSI: >
abort task & abort task set > > > >
Julian, > > iSCSI currently requires two responses to be returned
for an aborted > task - > one for the original task with a "good"
status, and the second for the > task > management function (TMF)
itself. So, the following legal behaviors > are > required
of a target - > a) plug the CmdSN gap if the command was
not received, > b) send a SCSI response and TMF response if
the task still is > active, > c) send a TMF response
if the task isn't active (if already > complete). > > I
would like to suggest that we reconsider our approach for case (b) >
for > a variety of reasons, to change it to: > b)
send a TMF response signalling that the abort is complete, if >
the > task > still is active. >
> Here are my reasons - > > 1. Target iSCSI
layer would need to make a SCSI response up on >
an abort of an active task. It then follows that the iSCSI >
layer > may have to make up several SCSI
responses on an 'abort task > set'. > > 2. The
current approach also creates a side effect that isn't > readily >
apparent for 'abort task set'. Initiators
would need to stall > processing >
'abort task set' TMF response till task responses (to account >
for > all >
the tasks in the task set) on multiple TCP connections >
(possibly on > different NICs) are received -
which I am afraid would > tantamount to >
an initiator scoreboard. > +++ That is not entirely correct. The
whole purpose of requiring the > target to send a "good status" is to
allow the initiator to send the > response immediately and have the
initiator mark its internal data > structures as aborted - but avoid
reusing ITT untill it gets the good > answer. > This way initiator
can make progress and it can be sure that it won't > be surprised by an
"old" answer after it has reused the ITT > +++ > 3.
The current approach complicates initiator implementations that >
want > to process a successful SCSI
completion even after they > initiated >
timeout processing since on an 'abort task set', initiators can >
never > be sure if the response was
pre-abort, or post-abort (made up > "good" >
status). I believe it is worth preserving this
implementation > choice. > +++ see above +++ > 4.
I am further concerned that iSCSI is possibly in violation of >
the > spirit of > SAM-2, rev20. >
- clause 5.6.2 that states - > "When an
initiator causes its own task(s) to be aborted, no >
notification > that the task(s) have been aborted shall be >
returned to the initiator other than the completion response for the >
command > or task management function action > that caused the
task(s) to be aborted and notification(s) associated > with >
related effects of the action (e.g., a target > reset unit attention
condition)." > +++ I did say explicitly that the good status is a
"good-will" message > between iSCSI target and initiator. It does not
have to reach SCSI. > SAM also allows statuses that have been sent
before an abort was > executed but received after the TM response to be
delivered or not at > initiators will +++ >
- clause 5.3.1 that states - > "GOOD. This status indicates that
the device server has successfully > completed the task." >
> I propose that the target deliver only the TMF response on an abort
of > an active task on an 'abort task' TMF, and not transmit an 'abort
task > set' > TMF response until all the current StatSN's on all
connections (as on > the > completion of "abort task set') in the
session are ack'ed. This ack > may be > solicited by way of
a NOP-IN with valid TTT. > > +++ that may result in an initiator
reusing prematurely an ITT and > being hit by a late arriving
status > for a "former" task - i.e. non-deterministic behavior
+++ > > This gives the determinism to initiators that (a)
abort task set TMF > response > signifies that the entire task set
had been dealt with, and (b) every > task > response > is a
true SCSI end-to-end reponse (not generated by iSCSI), besides >
doing > away with SCSI-response code in the target iSCSI layer. >
> Comments? Did I miss any corner cases? > > +++ see
above +++ > > Regards. > -- > Mallikarjun >
> Mallikarjun Chadalapaka > Networked Storage
Architecture > Network Storage Solutions Organization >
Hewlett-Packard MS 5668 > Roseville CA
95747
Home
Last updated: Fri Dec 14 17:17:48 2001
8075 messages in chronological order
|