Re: current multi-task abort model in RFC 3720

[William Studenmund <wrstuden@wasabisystems.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 21, 2006, at 8:05 PM, T.Krishnanand wrote:

> On 2/22/06, William Studenmund <wrstuden@wasabisystems.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Feb 18, 2006, at 10:16 PM, T.Krishnanand wrote:
> >
> >
> > I'm not fully clear what the issue is, but I think that you are
> > describing an initiator that does not understand TAS=1. With TAS=1,
> > tasks don't silently disappear. So you will get abort status on all
> > of them, regardless of which initiator triggered the abort.
>
> The issue that I was trying to raise was:
>
> TAS=1 implies tasks aborted by actions on OTHER nexus cause "TASK
> ABORTED" scsi status. But abort of tasks on the nexus on which TM cmd
> came are NOT notified to the initiator, only TM response is given.

True.

> So I was trying to confirm that iSCSI target MUST ensure that ALL
> "task aborted" scsi statuses are sent to TCP for transmission to
> init-B and only AFTER THAT it can send the lun-reset task mgmt
> response to init-B.
>
> So that init-B will ALWAYS first see all the "task aborted" scsi
> statuses (due to lun-reset from init-A) and THEN it'll see the
> lun-reset response from it's own lun-reset task mgmt cmd.
>
> IMHO this is important since if init-B see its own lun-reset response
> first the followed by the "task aborted" scsi statuses......then isn't
> it a violation of the SCSI spec which mandates...
>
> "once task mgmt cmd response is recvd...NO responses from
> chronologically older tasks can be recvd by an initiator."
>
> Hope this clarifies the "confirmation of target behaviour" I'm  
> seeking.

The way you have it phrased, I don't see why you had to ask. As  
outlined above, this is not an iSCSI issue, but a SCSI/SAM issue.

The place where things get difficult is in how you define "received."  
All you are requiring above is that the responses have been posted to  
the TCP stack. That's what most targets do AFAIK.

The problem is that in an MC/S environment, that doesn't mean that  
the initiator has gotten the status. Consider two connections, one of  
which has a task (or tasks) on it and the other which is used to send  
the TMR. Further let the first connection be suffering connectivity  
issues (say the intermediate switch and its friends are inefficiently  
updating a spanning-tree, so it's off line for a few tens of  
seconds). So the target sends the aborted response for the tasks  
aborted due to Intr-A, however they are stuck waiting for the switch.  
Now the TMF comes along, and completes. The TMF Response gets to the  
initiator without issue. Next the switches decide to carry traffic  
again, and the status messages arrive at the initiator.

I'm starting to think that the real fix for a number of these issues  
is actually to change things at the SCSI layer, and to come up with  
something akin to TAS & friends on steroids. Make it so that _every_  
task will receive status (unless there's an I_T Nexus Loss). Then a  
lot of these races disappear. I realize this isn't the best list to  
discuss this. :-)

Take care,

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFD/P76DJT2Egh26K0RArRdAJ94Z6T8T29SbQixlYI64PmJKjjNyQCePovJ
3vwTme/h8ZB816X/DmoSTTY=
=KTtd
-----END PGP SIGNATURE-----

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips