Re: current multi-task abort model in RFC 3720

["T.Krishnanand" <krishnanand.thommandra@gmail.com>]

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:
>
> > 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.
>
> 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.

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 ?

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

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