Clearing effects of logouts on different protocols
Mallikarjun C.
cbm at rose.hp.com
Thu Feb 21 15:42:31 PST 2002
* From the T10 Reflector (t10 at t10.org), posted by:
* "Mallikarjun C." <cbm at rose.hp.com>
*
Rob,
While your proposal is certainly the most expedient way to go,
I think we should discuss the architectural options and issues
behind the dichotomy first and make a choice. I have had offline
discussions with George Penokie, Ralph Weber and Randy Haagens
on this topic. As I indicated to you earlier, I am working on a
discussion paper on this topic, to be ready for Dallas. Assuming
that it gets agenda time, Randy is likely to present it.
BTW, iSCSI had originally adopted the approach that SRP is
considering - that of logouts not clearing reservations. We made
the change to "FCP-like" behavior very recently, and I am not
sure at the moment that it is the best option. That's what originally
prompted me to work on this discussion paper.
Regards.
--
Mallikarjun
Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747
----- Original Message -----
From: Elliott, Robert
To: t10 at t10.org
Sent: Thursday, February 21, 2002 9:49 AM
Subject: Clearing effects of logouts on different protocols
* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert" <Robert.Elliott at COMPAQ.com>
*
FCP/FCP-2 logical units release a classic (non-persistent) reservation
whenever the initiator holding the reservation logs out (see section 4.9
table 4 "Clearing effects of link related functions"). iSCSI is headed
down the same path (see Mallikarjun Chadalapaka's proposed clearing
effects table posted to the ips mailing list). pSCSI (Parallel SCSI),
on the other hand, has no login/logout process, so classic reservations
|from an idle initiator persist until power loss (or bus reset,
TARGET RESET, or LOGICAL UNIT RESET).
In the last SRP conference call, we discussed a letter ballot comment
|from George Penokie requesting that logouts NOT clear reservations -
following pSCSI rather than FCP. In earlier SRP discussions, it was
proposed that targets might force logouts in busy systems to reclaim
resources from idle initiators. The initiator could login later
when it has work to do. If we follow FCP semantics and let this
have side-effects, however, it might not be a good idea.
Any differences in the protocols make protocol bridges difficult to
implement. FC to pSCSI bridges (routers) face this issue today.
I'd like SRP to iSCSI, iSCSI to FC, SRP to FC, etc. bridges to
have an easier time.
Assume a FC initiator is using a pSCSI target which is presented as
a FC target by a bridge. If the FC initiator has a reservation and
logs out, the FC initiator software can assume its reservation was
cleared. The pSCSI target, though, will continue to hold the
reservation; it didn't see the logout.
This can be handled if the bridge sends a LOGICAL UNIT RESET task
management function to the pSCSI target whenever a FCP logout occurs.
This is a bit cumbersome and I don't know if any bridges do this.
The same concerns apply to mode pages (reverting to default or saved),
log pages (revert to saved or default), reporting of ACA/unit
attention/deferred errors (lost), etc.
One suggestion in the call was to add a new optional bit to the control
mode page that instructs the logical unit to save everything across
logouts. This bit is protocol-independent. The protocol-related
effect of the bit is to violate the protocol standard's clearing
effects rules (for FCP-2). New protocol standards could be cognizant
of the bit and mention how it changes their clearing effect rules.
All the fabric protocols (any protocol that has the login/logout
concept) would continue to default to clearing everything. New
protocols would mention that this bit exists and changes the
clearing effects.
Targets on any protocol could implement the bit, offering software
new friendlier semantics. pSCSI targets could implement the bit
to relieve bridges of the need to send LOGICAL UNIT RESET to keep
them in sync with fabric logouts.
Bit set to 0 means the behavior is protocol-specific like today;
some protocols clear, others don't.
Bit set to 1 means the behavior is well defined (don't clear
anything except on power cycles, TARGET RESET, or LOGICAL
UNIT RESET).
The questions are:
* should iSCSI clear or not?
* should SRP clear or not?
* should we add a control mode page bit to allow not clearing?
* should mode pages/log pages/etc. all be handled the same?
---
Rob Elliott, Compaq Server Storage
Robert.Elliott at compaq.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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