Clearing effects of logouts on different protocols

Robert Snively rsnively at Brocade.COM
Fri Mar 1 08:47:03 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>
*
This is a fascinating question.

However, the most important answer is that:

	Reserve/Release is an obsolete function used in
	simple and restricted environments.

	Persistent Reservation was invented explicitly
	to address the problems associated with networked
	devices and is presently implemented by all
	high performance disk devices, most high performance
	RAID devices, and those operating systems that
	behave well in highly networked SANs.

So how much do we want to bend architectures to support
legacy commands?  My answer would be not much.  Our best
bet would be to obsolete Reserve/Release.

Secondary to that is a true architectural question.

	When is a device part of a SAN?

	In pSCSI, it is only part of a SAN when it is plugged
	in and powered on.  Physical configuration is the
	implicit session login function.

	In FCP, iSCSI, and I hope SRP, physical
	configuration has nothing to do with the actual
	SAN configuration.  Before a device can be anything
	other than an FC or IP node, it must first be
	zoned/scoped into a set of mutually accessible nodes,
	then personalized as a SCSI device, then (through a
	session login or equivalent function) partnered with a
	set of other SCSI devices.  Before that is all complete,
	it is just a connector on a wire and has no other 
	properties than a connector.  Legacy reservations 
	are states that only exist after the domain of mutually
	accessible SCSI devices has been established, and should
	be cleared by those devices that are not part of such
	a domain.  Persistent reservations (because they have
	additional controls and monitors that can actually 
	identify the existence of reservations, identify the
	reservation holder, and preempt the reservation) are
	very much part of a device's long term state, even if
	it has been powered off and moved to another network.

Bob 

> -----Original Message-----
> From: Elliott, Robert [mailto:Robert.Elliott at COMPAQ.com]
> Sent: Thursday, February 21, 2002 9:50 AM
> To: t10 at t10.org
> 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