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