Re: iSCSI: abort task & abort task set

[Patrick Stirling <pms@veritas.com>]

I've been lurking silently on this list for a while, but would like to
throw in my opinion here!

I agree with Mallikarjun's proposal that the iSCSI target layer should not
send responses for individual commands on receiving an Abort Task Set task
mgmt command. I think it breaks the layering (command responses should be
end to end).

Julo commented:

> +++ 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 +++

Perhaps I'm missing something here - when would the initiator send a
response to the target? Surely the Abort is intended to kill the command
immediately.

Secondly, the initiator should not reuse task tags until it knows the
status of the previous command - and it can't know this until the target
responds to the TMF. With a 32 bit task tag I don't see a problem with
running out of tag values!

So the requirement is that the target abort all commands with a SN less
than that of the TMF itself, then respond to the TMF. Receipt of the TMF
response indicates that the initiator can clean up for all aborted
commands. I don't see that it's an undue burden on the initiator to retain
the per-command information until then.

As an editorial aside, I find ACA and TMF very confusing - anything we can
do to simplify them is good!

patrick
Patrick Stirling
VERITAS Software Corp.