|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI: abort task & abort task set
Julian,
Based
on how the protocol is specified, the initiator could determine that the
target
has
violated the protocol. Assume that the initiator did not send a status ACK
because
there
was no real reason to do so, and it is waiting for a time-out or some
such
condition before sending the status ack. If the status
for the task management command
is
received in the meantime, it is a good thing, although not necessarily compliant
with
the
spec (unless the spec is changed).
I
think it is a good idea to add this text to the spec.
Also
perhaps in the spec text, it should be mentioned that the initiators are
encouraged to
send
status acks aggressively when they send a task management request is sent
(till
the
task management status is received).
Somesh
Somesh,
"Somesh Gupta"
<somesh_gupta@silverbacksystems.com> wrote on 14-12-2001
20:52:04:
> 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? > >
I assume that you are on safe
ground as the target is doing it and no one could be wiser (no way to observe extrnally any difference) and
there is no need to specify this behavior. Or is it? > > 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. > > Statuses are recovered
by SNACK. I doubt initiators will retry abborted commands!
> > Somesh > >
-----Original Message----- > From: owner-ips@ece.cmu.edu
[mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran >
Sent: Monday, December 03, 2001 10:51 PM > To: ips@ece.cmu.edu >
Subject: Re: iSCSI: abort task & abort task set > > > 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: Sun Dec 16 13:17:45 2001
8088 messages in chronological order
|