Clearing effects of logouts on different protocols

JoeBre at exabyte.com JoeBre at exabyte.com
Thu Mar 7 12:08:51 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_01C1C613.E6972D30
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message----- 
> From: Robert Snively [ mailto:rsnively at brocade.com
 ] 
> Sent: Wednesday, March 06, 2002 3:18 PM 
> To: 'JoeBre at exabyte.com'; Robert Snively; t10 at t10.org 
> Subject: RE: Clearing effects of logouts on different protocols 
> 
> 
> 
> -- 
> > 
> >       Folks, fortunately, this is addressed by the recommended 
> >       treatment of MODE SELECT established parameters in 
> >       tape drives.  While "saved" parameters are recommended, 
> >       implicit default parameters established by the 
> >       state information about the tape (including position, 
> >       compression parameters, and presumably partition 
> >       information) should now be required. 
> 
> What is the "recommended treatment"? Did I miss a proposal? What is an

> "implicit default" parameter? If I am reading FCP-2 rev 7a 
> correctly, table 
> 4 mandates that a PLOGI will require "Target mode page 
> parameters restored 
> from saved pages (when saved pages are supported, or default mode page

> parameters when saved pages are not supported)". Granted, 
> this is the case 
> "Only for initiator port associated with the action", but some mode 
> parameters are inherently device-wide. 
> To outline one of the problem scenarios once again, an 
> initiator A may be 
> happily writing to my partition 2. He may have navigated to 
> partition 2 by 
> means of a MODE SELECT, but he may have navigated there by means of a 
> LOCATE. Initiator B may thereby boot. As 'hosts' are wont to 
> do, initiator B 
> does a PLOGI to me. This causes saved mode page parameters to 
> be restored, 
> as mandated by FCP-2 rev 7a, table 4. The saved mode page 
> parameters may 
> specify some other partition (let's assume 0). The tape 
> repositions to BOP 
> 0. Initiator A issues a subsequent WRITE command, assuming 
> that the current 
> position has not been altered. This subsequent WRITE ends up 
> writing over 
> Partition 0, LBA 0. Data loss has occurred. Note that this cannot be 
> eliminated by means of reservations - classic or persistent. 
> The above scenario is only one of many where data loss may 
> occur, due to the 
> clearing effects of link related functions. I believe that 
> even DASD devices 
> are not immune. What about the rigid disk device geometry page? 
> 
>       See SSC-2 clause 8.3.1: 
> 
>       "The device-specific parameters contained in the 
>       mode parameter header, mode block descriptor values, 
>       and Data Compression mode page shall be retained 
>       following a reset condition (e.g., Target Reset, 
>       SCSI Logical Unit Reset, Fibre Channel Reset LIP or PLOGI). 
>       NOTE 44 This is to facilitate continued operation 
>       for applications such as backup/restore following 
>       a reset event." 

Is that the definition of an "implicit default parameter"? It is nice
text, but it does not solve the problem on several grounds:

- It does not specify that the current active partition, as embodied in
the Device Configuration page, is not among those items whose state is
to be maintained

- If 8.3.1 were altered to include the Device Configuration page, the
current partition may not be the one specified in the last received MODE
SELECT. An initiator may have subsequently LOCATEd to some other
partition.

- What of the case of a Fibre Channel SSC(-1) tape? Is it to be
orphaned? 
- What of the case of DASD Rigid Disk Geometry page? May the mapping of
physical sectors to LBAs not be reset to [saved | default] values by a
PLOGI?   

>       "f) following a reset condition occurring while ready, 
>       the device server shall retain knowledge of the density 
>       code as determined by items B) through D) above." 
> 
> > >More fundamentally, 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. 
> > 
> >       There is a lot of discussion that can be had about this. 
> 
> Perhaps that discussion *should* be had. While I may have missed some 
> relevant discussion, I do not recall any argument being 
> advanced to state 
> that the clearing effects of 'port level stuff' upon 'logical 
> unit level 
> stuff' is A Good Thing. 
> Interestingly, PRLI was granted specific exemptions in FCP-2 
> regarding these 
> effects (table 6). At some point, someone must have 
> considered the negative 
> aspects of these effects upon the logical unit layer. To not 
> grant the same 
> exemptions to PLOGI seems counter-intuitive at best. 
> 
>       Basically, the approach that has been taken in most 
>       of the protocols is to replicate the behavior that generic 
>       driver software would see for corresponding physical changes 
>       (configuration, device installation, etc.) for 
>       SCSI-2/SPI-x compliant devices in the new protocols. 

That seems an eminently sensible approach. I do not, however, see how
mandating that PLOGI has a clearing effect upon Mode page data adds to
this goal. It rather seems to directly contravene this stated goal.

>       The network management (including the definition of 
>       nodes, discovery of topology, and most other functions) 
>       is viewed as orthogonal to the SCSI operations.  

I agree that the orthangonality of network managment to SCSI operations
is A Good Thing. My contention is that to have 'port level things'
affect 'logical unit level things' is a *violation* of this
orthogonality principle. To have PLOGI effect changes at the logical
unit layer (as in clearing mode parameters) is to have an (apparently)
unneccessary binding of the layers.

>     Once 
>       a configuration is established by network management, 
>       normal SCSI operation is expected.  

FWIW, It would not be so bad if SCSI operations could proceed only
"*ONCE* a configuration is established by network management" [emphasis
added]. The problem is that PLOGI, on any SAN of non-trivial size, is a
recurrent condition (proper use of PDISC/ADISC notwithstanding).

>     Another way to phrase 
>       this is to say that SCSI login operations are NOT part 
>       of SCSI operation, since SPI-x compliant devices and their 
>       supporting software are unaware of such behaviors. 

Right. So why have port level login activity do damage to existing SCSI
level behaviors? 

>       The layering was essentially at the CAM level.  

Yet it seems to me that FCP-2 table 4 is mandating that changes 'below'
the CAM abstraction layer reach up and across the layer boundary to
meddle with upper-level state.

>     This 
>       preserves present software as much as possible.  

Perhaps I am just being blind, but it appears to me that the clearing
effect under discussion *breaks* existing software, but that
*elimintaing* the clearing effects of PLOGI upon mode parameters *would*
preserve existing software.

>     However, 
>       some present software is not very good at handling 
>       multiple initiator environments, whether networked or not, 
>       and therefore continues to use legacy reservations and 
>       to issue device resets.  

I am not particularly concerned about the fact that *some* software is
incompatible with multi-initiator environments. Presumably, this issue
will rectify itself in the marketplace, with sophisticated admins
knowing to to ask about such support, and integrators steering end users
to the solutions that meet their needs. Rather, I am worried about the
situation where the underlying specifications *preclude* the ability to
build implementations that can work.

>     Other implementations are quite 
>       good at handling this and use persistent reservations for 
>       everything from device protection to cluster quorum management. 

Thanx for the continued discussion, 
Joe Breher 
Exabyte Corp 


------_=_NextPart_001_01C1C613.E6972D30
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 

> -----Original Message----- 
> From: Robert Snively [mailto:rsnively at brocade.com] 
> Sent: Wednesday, March 06, 2002 3:18 PM 
> To: 'JoeBre at exabyte.com'; Robert Snively; = t10 at t10.org 
> Subject: RE: Clearing effects of logouts on = different protocols 
> 
> 
> 
> -- 
> > 
> >       Folks, = fortunately, this is addressed by the recommended 
> >       = treatment of MODE SELECT established parameters in 
> >       tape = drives.  While ;saved; parameters are recommended, = 
> >       = implicit default parameters established by the 
> >       state = information about the tape (including position, 
> >       = compression parameters, and presumably partition 
> >       = information) should now be required. 
> 
> What is the ;recommended treatment;? = Did I miss a proposal? What is an 
> ;implicit default; parameter? If I am = reading FCP-2 rev 7a 
> correctly, table 
> 4 mandates that a PLOGI will require = ;Target mode page 
> parameters restored 
> from saved pages (when saved pages are = supported, or default mode page 
> parameters when saved pages are not = supported);. Granted, 
> this is the case 
> ;Only for initiator port associated with = the action;, but some mode 
> parameters are inherently device-wide. 
> To outline one of the problem scenarios once = again, an 
> initiator A may be 
> happily writing to my partition 2. He may have = navigated to 
> partition 2 by 
> means of a MODE SELECT, but he may have = navigated there by means of a 
> LOCATE. Initiator B may thereby boot. As = 'hosts' are wont to 
> do, initiator B 
> does a PLOGI to me. This causes saved mode page = parameters to 
> be restored, 
> as mandated by FCP-2 rev 7a, table 4. The saved = mode page 
> parameters may 
> specify some other partition (let's assume 0). = The tape 
> repositions to BOP 
> 0. Initiator A issues a subsequent WRITE = command, assuming 
> that the current 
> position has not been altered. This subsequent = WRITE ends up 
> writing over 
> Partition 0, LBA 0. Data loss has occurred. = Note that this cannot be 
> eliminated by means of reservations - classic = or persistent. 
> The above scenario is only one of many where = data loss may 
> occur, due to the 
> clearing effects of link related functions. I = believe that 
> even DASD devices 
> are not immune. What about the rigid disk = device geometry page? 
> 
>       See SSC-2 clause = 8.3.1: 
> 
>       ;The = device-specific parameters contained in the 
>       mode parameter = header, mode block descriptor values, 
>       and Data = Compression mode page shall be retained 
>       following a = reset condition (e.g., Target Reset, 
>       SCSI Logical = Unit Reset, Fibre Channel Reset LIP or PLOGI). 
>       NOTE 44 This is = to facilitate continued operation 
>       for applications = such as backup/restore following 
>       a reset = event.; Is that the definition of an ;implicit default = parameter;? It is nice text, but it does not solve the problem on = several grounds: - It does not specify that the current active = partition, as embodied in the Device Configuration page, is not among = those items whose state is to be maintained - If 8.3.1 were altered to include the Device = Configuration page, the current partition may not be the one specified = in the last received MODE SELECT. An initiator may have subsequently = LOCATEd to some other partition. - What of the case of a Fibre Channel SSC(-1) tape? = Is it to be orphaned? 
- What of the case of DASD Rigid Disk Geometry page? = May the mapping of physical sectors to LBAs not be reset to [saved | = default] values by a PLOGI?   >       ;f) = following a reset condition occurring while ready, 
>       the device = server shall retain knowledge of the density 
>       code as = determined by items B) through D) above.; 
> 
> > >More fundamentally, 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. 
> > 
> >       There = is a lot of discussion that can be had about this. 
> 
> Perhaps that discussion *should* be had. While = I may have missed some 
> relevant discussion, I do not recall any = argument being 
> advanced to state 
> that the clearing effects of 'port level stuff' = upon 'logical 
> unit level 
> stuff' is A Good Thing. 
> Interestingly, PRLI was granted specific = exemptions in FCP-2 
> regarding these 
> effects (table 6). At some point, someone must = have 
> considered the negative 
> aspects of these effects upon the logical unit = layer. To not 
> grant the same 
> exemptions to PLOGI seems counter-intuitive at = best. 
> 
>       Basically, the = approach that has been taken in most 
>       of the protocols = is to replicate the behavior that generic 
>       driver software = would see for corresponding physical changes 
>       (configuration, = device installation, etc.) for 
>       SCSI-2/SPI-x = compliant devices in the new protocols. That seems an eminently sensible approach. I do not, = however, see how mandating that PLOGI has a clearing effect upon Mode = page data adds to this goal. It rather seems to directly contravene = this stated goal. >       The network = management (including the definition of 
>       nodes, discovery = of topology, and most other functions) 
>       is viewed as = orthogonal to the SCSI operations.  I agree that the orthangonality of network managment = to SCSI operations is A Good Thing. My contention is that to have 'port = level things' affect 'logical unit level things' is a *violation* of = this orthogonality principle. To have PLOGI effect changes at the = logical unit layer (as in clearing mode parameters) is to have an = (apparently) unneccessary binding of the layers. >     Once 
>       a configuration = is established by network management, 
>       normal SCSI = operation is expected.  FWIW, It would not be so bad if SCSI operations could = proceed only ;*ONCE* a configuration is established by network = management; [emphasis added]. The problem is that PLOGI, on any = SAN of non-trivial size, is a recurrent condition (proper use of = PDISC/ADISC notwithstanding). >     Another way to = phrase 
>       this is to say = that SCSI login operations are NOT part 
>       of SCSI = operation, since SPI-x compliant devices and their 
>       supporting = software are unaware of such behaviors. Right. So why have port level login activity do = damage to existing SCSI level behaviors? >       The layering was = essentially at the CAM level.  Yet it seems to me that FCP-2 table 4 is mandating = that changes 'below' the CAM abstraction layer reach up and across the = layer boundary to meddle with upper-level state. >     This 
>       preserves = present software as much as possible.  Perhaps I am just being blind, but it appears to me = that the clearing effect under discussion *breaks* existing software, = but that *elimintaing* the clearing effects of PLOGI upon mode = parameters *would* preserve existing software. >     However, 
>       some present = software is not very good at handling 
>       multiple = initiator environments, whether networked or not, 
>       and therefore = continues to use legacy reservations and 
>       to issue device = resets.  I am not particularly concerned about the fact that = *some* software is incompatible with multi-initiator environments. = Presumably, this issue will rectify itself in the marketplace, with = sophisticated admins knowing to to ask about such support, and = integrators steering end users to the solutions that meet their needs. = Rather, I am worried about the situation where the underlying = specifications *preclude* the ability to build implementations that can = work. >     Other implementations = are quite 
>       good at handling = this and use persistent reservations for 
>       everything from = device protection to cluster quorum management. Thanx for the continued discussion, 
Joe Breher 
Exabyte Corp 
------_=_NextPart_001_01C1C613.E6972D30--




More information about the T10 mailing list