Clearing effects of logouts on different protocols

JoeBre at exabyte.com JoeBre at exabyte.com
Fri Mar 1 13:43:48 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* JoeBre at exabyte.com
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1C16A.2BA8A010
Content-Type: text/plain;
	charset="iso-8859-1"

Bob (at al) - 

I can agree with your desire to strongly discourage classic
Reserve/Release for contemporary environments. The avoidance of this
mechanism conveniently sidesteps any adverse effects of the clearing
effects of (for instance) PLOGI upon reservations.

However, the issue I posted yesterday still stands. For better or worse
(admittedly mostly for worse), SCSI has traditionally allowed for
specifying (for instance) the current partition upon a tape through the
use of MODE SELECT. To reiterate, due to this fact, booting a
workstation on a SAN may lead to data loss. Note that, unlike the case
of the reservation issue, there is no way to guard against this issue,
unless FCP-2 clearing effects are redefined.

More fundametally, there exists an architectural layering issue. Why
should activities at the port layer effect changes at the logical unit
layer? I contend that this is an encapsulation issue, violating commonly
accepted layering principles.

If a host coming online wants to count on a known initial state of an
FCP-x device, they always have the ability to perform PLOGI/PRLI/LOGICAL
UNIT RESET. The clearing effects of login are not necessary for this
funcitonality.

Joe Breher 
Exabyte Corp 

> -----Original Message----- 
> From: Robert Snively [ mailto:rsnively at brocade.com
 ] 
> Sent: Friday, March 01, 2002 9:47 AM 
> To: t10 at t10.org 
> Subject: RE: Clearing effects of logouts on different protocols 
> 
> 
> * 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 
> 


------_=_NextPart_001_01C1C16A.2BA8A010
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

RE: Clearing effects of logouts on different protocols Bob (at al) - I can agree with your desire to strongly discourage = classic Reserve/Release for contemporary environments. The avoidance of = this mechanism conveniently sidesteps any adverse effects of the = clearing effects of (for instance) PLOGI upon reservations. However, the issue I posted yesterday still stands. = For better or worse (admittedly mostly for worse), SCSI has = traditionally allowed for specifying (for instance) the current = partition upon a tape through the use of MODE SELECT. To reiterate, due = to this fact, booting a workstation on a SAN may lead to data loss. = Note that, unlike the case of the reservation issue, there is no way to = guard against this issue, unless FCP-2 clearing effects are = redefined. More fundametally, there exists an architectural = layering issue. Why should activities at the port layer effect changes = at the logical unit layer? I contend that this is an encapsulation = issue, violating commonly accepted layering principles. If a host coming online wants to count on a known = initial state of an FCP-x device, they always have the ability to = perform PLOGI/PRLI/LOGICAL UNIT RESET. The clearing effects of login = are not necessary for this funcitonality. Joe Breher 
Exabyte Corp > -----Original Message----- 
> From: Robert Snively [mailto:rsnively at brocade.com] 
> Sent: Friday, March 01, 2002 9:47 AM 
> To: t10 at t10.org 
> Subject: RE: Clearing effects of logouts on = different protocols 
> 
> 
> * 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.c= om] 
> > 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 
> 
------_=_NextPart_001_01C1C16A.2BA8A010--




More information about the T10 mailing list