Reservations discussion posted

Mallikarjun C. cbm at rose.hp.com
Thu Feb 28 09:56:17 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Mallikarjun C." <cbm at rose.hp.com>
*
Cris,

Sorry, it took us a while to complete revision 1 of the proposal.
It is now uploaded to the T10 website:

ftp://ftp.t10.org/t10/document.02/02-078r1.pdf

This answers your question on the need to terminate the tasks
on session termination.  The related text of the updated draft is
attached below.

I would like us to discuss this updated draft if possible in the
SRP conf call tomorrow.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747


----- Original Message -----
From: "Simpson, Cris" <cris.simpson at intel.com>
To: <t10 at t10.org>
Cc: <cbm at rose.hp.com>
Sent: Wednesday, February 27, 2002 5:32 PM
Subject: RE: Reservations discussion posted


>
> Mallikarjun,
>
>
> > I uploaded the "Reservations & Nexus" discussion
> > paper to the T10 website over the weekend.
> >
> > ftp://ftp.t10.org/t10/document.02/02-078r0.pdf
> >
>
>  Could you clarify the second bullet of the Option A 'Cons'?
>
>      * Does not address the requirement that all tasks be
>        terminated deterministically on both ends when the
>        "login session" collapses for networked transports.
>
>   Where is this requirement stated?
>   What exactly does "terminated deterministically on both ends" mean?
>
>
> Thanks,
> Cris
>
>
> --
> Cris Simpson                                          503.712.4333
> Intel EPG/ACD Architecture                           Hillsboro, OR
> PGP Fingerprint:0DA0 418E A27B 0B76 5F02  3DD4 0546 6D13 F88A 1E60
>

-------------------------------------------------------------------------------------
---
3.2.2.Active tasks must be terminated when a transport session collapses

If tasks were to exist beyond a session failure, they would find themselves stranded
on the target,

which has no clue as to the expected lifetime of each of the tasks. The session
failure however

does not present any serious issues on the initiator - each task times out
individually and the

appropriate task cleanup happens.

A target really has only two alternatives to deal with a set of stranded tasks -

. terminate all the tasks along with the session failure - which is what FCP-2
specifies, and so

does iSCSI.

. timeout the tasks after "sometime"

(a) There is no SCSI-level way of conveying the expected lifetime for the tasks from
the ini-tiator

- so the "sometime" is undefined, and likely to be implementation or even context

dependent.

(b) Assuming that target picked an arbitrary value, this is an asymmetric timeout -
the initia-tor

may have terminated tasks long before the target did, and could re-use the same task

tags (FC FQ_XID, or iSCSI ITT) on a new instantiation of the I_T_L nexus causing

conflicts with target view. Or worse still, the initiator may attempt to continue the
tasks

on a new instantiation of the I_T_L nexus when the target had already terminated
them.

Terminating the active tasks with the transport session failure/closure is the only
decent choice.

This paper explores the right object relationships that result in this desired
behavior.


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list