Subject: [Ips] iSCSI: Terminating active tasks

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 27 Jan 2004 11:44:45 -0500

Suppose an active task is terminated due to a lost connection (item b below). When the connection is re-instated, should the active tasks get a check condition?

Note that there appeared to be a clarification added to draft 20+errata but that didn't make it into the final draft (as I remember, there were other objections to the errata). I don't know if the new wording is incorrect or if it is implied by draft 20's wording and therefore not necessary.

Can someone please give me your interpretation of the following?

draft 20:

If the tasks terminated in the above cases a), b, c) and d)are SCSI
tasks, they must be internally terminated as if with CHECK CONDITION
status. This status is only meaningful for appropriately handling
the internal SCSI state and SCSI side effects with respect to
ordering because this status is never communicated back as a
terminating status to the initiator. However additional actions may
have to be taken at SCSI level depending on the SCSI context as
defined by the SCSI standards (e.g., queued commands and ACA, UA for
the next command on the I_T nexus in cases a), b), and c) etc. - see
[SAM] and [SPC3]).

draft 20+errata:

[--same as above to here--] (e.g., queued commands and ACA, in
cases a), b), and c), after the tasks are terminated, the target
MUST report a unit attention condition on the next command processed
on any connection for each affected I_T_L nexus etc. - see [SAM] and
[SPC3]).

Eddy

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 27 Jan 2004 11:18:43 -0800

Eddy,

Check the -02 revision of the command ordering draft,
section 5 "connection failure considerations".  The
"affected I_T_L nexus" as used in that draft is each
I_T_L nexus for LUs that the iSCSI session can get to.

Yes, there's a requirement for a UA.  But note that
the requirement is not related to connection reinstatement
per se.  And not all active tasks get check conditions
either.  Only the first task on each I_T_L nexus is
affected.

Hope that helps.

Mallikarjun

Eddy Quicksall wrote:

> Suppose an active task is terminated due to a lost connection (item b 
> below). When the connection is re-instated, should the active tasks get 
> a check condition?
>  
> Note that there appeared to be a clarification added to draft 20+errata 
> but that didn't make it into the final draft (as I remember, there were 
> other objections to the errata). I don't know if the new wording is 
> incorrect or if it is implied by draft 20's wording and therefore not 
> necessary.
>  

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

---

From: "Eddy Quicksall" <[email-masked]>
Date: Wed, 28 Jan 2004 09:14:34 -0500

Thanks, that clears it up.

But I see an implementation issue in regards to a SCSI target layer that
interfaces to more than one type of transport. If that layer is going to
give this UA, then it wouldn't apply to future transports that also have a
similar connection issue.

Wouldn't it be better if the UA was more generic? Perhaps eliminating the
word "ISCSI". ("SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT").

Eddy

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 28 Jan 2004 10:03:08 -0800

> word "ISCSI". ("SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT").

That would have been my preference as well.

OTOH, I don't believe this is an issue per se
for implementations - transport is specifying
SCSI's return values on conditions unique to
the transport (so does FCP), implementations
should take that into account.

Mallikarjun