Subject: [Ips] current multi-task abort model in RFC 3720

From: T.Krishnanand <[email-masked]>
Date: Sun, 19 Feb 2006 11:46:50 +0530

Folks,

I'm aware that a new multi-task model is being discussed on the mlist
these days. But the following questions are based on the CURRENT
RFC3720 model...and what initiators support TODAY.

Consider a scenario where multiple iSCSI initiators are sharing a
READ-ONLY (no SCSI reservations) access to a common LUN which has
advertized TAS=1 control mode page setting.

If LUN-reset from init-A and init-B happen on same lun then is it OK if
LUN-reset response to init-B TM cmd is sent AFTER "task aborted" scsi
status is sent to init-B for tasks aborted becoz of init-A's
LUN-reset.

IMHO after receiving the TM response wont init-B think that ALL
outstanding tasks are aborted and hence MAY be surprised to recv scsi
status for tasks which were outstanding when the LUN-reset was issued
from init-B.

IMHO think this scenario should be handled as follows, plz confirm if
my understanding is correct.

1)  start processing LUN-reset from init-A
2)  send TM response to init-A AFTER sending out "task aborted" scsi
status for tasks of init-B that were outstanding.
3) start processing LUN-reset from init-B. (At this time all init-B
tasks aborted by init-A's LUN-reset have been notified to the init-B).

Plz comment.

-tkrishna

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: William Studenmund <[email-masked]>
Date: Tue, 21 Feb 2006 11:37:52 -0800

> status for tasks which were outstanding when the LUN-reset was issued

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.

> tasks aborted by init-A's LUN-reset have been notified to the init-B).

I think that is what targets will do today.

One major aspect of the discussion is what exactly is meant by,  
"sending out," in your step 2. Does it mean that we have assigned  
status to the task and we have passed a SCSI Command Response to the  
tcp stack, or does it mean that we have done that and further that we  
know the initiator has responded it has received the status?

On a data-center SAN with working initiators, it doesn't make much  
difference. Add the public internet and/or ill initiators and it  
becomes problematic.

Take care,

Bill

---

From: T.Krishnanand <[email-masked]>
Date: Wed, 22 Feb 2006 09:35:53 +0530

On 2/22/06, William Studenmund <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

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.

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.

Another related question is:

Do you know if the CURRENT breed of initiators will properly handle
TAS=1 support from a target ?

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFD+2wVDJT2Egh26K0RAtLdAJ4zxQUjmXYC4+ewW1fiAI7Xy+KwtwCdEjtP
> vC+p34JTdPPt3SQG65mAYEw=
> =FFyo
> -----END PGP SIGNATURE-----
>

---

From: William Studenmund <[email-masked]>
Date: Wed, 22 Feb 2006 16:16:53 -0800

> came are NOT notified to the initiator, only TM response is given.

True.

> Hope this clarifies the "confirmation of target behaviour" I'm  

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