Clearing effects of logouts on different protocols

Dave Peterson dap at cisco.com
Fri Mar 8 12:50:20 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Dave Peterson" <dap at cisco.com>
*
This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C1C6B0.919947D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Keep in mind that it is the OS tape driver/application that knows what
going on.
In practice, the OS tape driver/application will ensure the logical unit
is in the proper state (from the drivers viewpoint) before reading or
writing to the device.
If there is anything that would cause an undetected change thus opening
a data integrity hole, it needs to be fixed or at least understood.
 
What we need to do is to make sure the OS tape driver/application can
continue to operate (within reason) across events e.g., reset
conditions.
If maintaining knowledge of the current partition is required for
continued operation we should make every attempt to do so.
 
One issue with using mode select to change the partition is that some
devices do not allow a change if not at BOP.
(BTW, the mode select method to change partitions has since been
obsoleted in favor of LOCATE.)
Same thing was mentioned regarding data compression, although I am not
aware of any rule stating that data compression can only be changed at
BOx.
 
In your scenario below,  will not a Unit Attention condition occur
indicating a mode parameters have changed?
Also, does the tape drive reposition to partition 0 by itself?
 
We have time to discuss this subject when applied to tape at the next
SSC-2 meeting.
Dave 

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of
JoeBre at exabyte.com
Sent: Thursday, March 07, 2002 2:09 PM
To: rsnively at Brocade.COM; t10 at t10.org
Subject: 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_000_002E_01C1C6B0.919947D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

RE: Clearing effects of logouts on different = protocols Keep=20 in mind that it is the OS tape driver/application that knows what going = on.
 In=20 practice, the OS tape driver/application will ensure the logical unit = is in the=20 proper state (from the drivers viewpoint) before reading or writing to = the=20 device.
 If=20 there is anything that would cause an undetected change thus = opening a data=20 integrity hole, it needs to be fixed or at least = understood.
  
 What=20 we need to do is to make sure the OS tape driver/application can = continue to=20 operate (within reason) across events e.g., reset=20 conditions.
 If=20 maintaining knowledge of the current partition is required for = continued=20 operation we should make every attempt to do so.
  
 One issue with using mode select to change the partition = is=20 that some devices do not allow a change if not at = BOP.
 (BTW,=20 the mode select method to change partitions has=20 since been obsoleted in favor of LOCATE.)
 Same=20 thing was mentioned regarding data compression, although I am not aware = of any=20 rule stating that data compression can only be changed at=20 BOx.
  
 In=20 your scenario below,  will not a Unit Attention condition occur = indicating=20 a mode parameters have changed?
 Also,=20 does the tape drive reposition to partition 0 by = itself?
  
 We=20 have time to discuss this subject when applied to tape at the next = SSC-2=20 meeting.
 Dave 
 -----Original Message-----
From: owner-t10 at t10.org = [mailto:owner-t10 at t10.org]On Behalf Of=20 JoeBre at exabyte.com
Sent: Thursday, March 07, 2002 2:09=20 PM
To: rsnively at Brocade.COM; t10 at t10.org
Subject: = RE:=20 Clearing effects of logouts on different=20 protocols




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

------=_NextPart_000_002E_01C1C6B0.919947D0--




More information about the T10 mailing list