Reservations discussion posted
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>
Sorry, it took us a while to complete revision 1 of the proposal.
It is now uploaded to the T10 website:
This answers your question on the need to terminate the tasks
on session termination. The related text of the updated draft is
I would like us to discuss this updated draft if possible in the
SRP conf call tomorrow.
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
> > 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?
> 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
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
. timeout the tasks after "sometime"
(a) There is no SCSI-level way of conveying the expected lifetime for the tasks from
- so the "sometime" is undefined, and likely to be implementation or even context
(b) Assuming that target picked an arbitrary value, this is an asymmetric timeout -
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
on a new instantiation of the I_T_L nexus when the target had already terminated
Terminating the active tasks with the transport session failure/closure is the only
This paper explores the right object relationships that result in this desired
* 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