Clearing effects of logouts on different protocols

JoeBre at exabyte.com JoeBre at exabyte.com
Fri Mar 8 16:38:41 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_01C1C702.C30AC710
Content-Type: text/plain;
	charset="iso-8859-1"


-----Original Message----- 
From: Dave Peterson [ mailto:dap at cisco.com  ] 
Sent: Friday, March 08, 2002 1:50 PM 
To: JoeBre at exabyte.com; rsnively at brocade.com; t10 at t10.org 
Subject: RE: Clearing effects of logouts on different protocols 


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.

<Joe> 
I don't know how an application client (driver/application) in one
initiator would have any idea that some other initiator (or other
FC-capable thingy -- not necessarily SCSI) performed a PLOGI to the tape
device (target it was communicating with). As such, the OS tape
driver/application does not know what is going on. The state of the
device has been changed out from underneath it. Reservations, whether
classic or persistent, do not prevent this from happening, as it can be
the PLOGI that caused mandated state changes.

</Joe> 

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.

<Joe> 
Agreed. Perhaps we can do this for SSC-2. SSC(-1) devices will still be
problematic, as will disk devices (geometry pages). I would not be
surprised if other device models would exhibit similar problems, due to
the clearing effects of PLOGI upon mode pages, if examined.

</Joe> 

One issue with using mode select to change the partition is that some
devices do not allow a change if not at BOP. 

<Joe> 
That may be, but I see nothing in SSC that mandates that partition can
be changed only when positioned at BOP. There certainly exist
implementations in the field that do not have this restriction. Even so,
I'm not sure that has any bearing on the identified problem.

</Joe> 

(BTW, the mode select method to change partitions has since been
obsoleted in favor of LOCATE.) 

<Joe> 
As well it should. We probably never should have had two ways to change
partitions to begin with. We do, we learn, we grow. Be that as it may,
tape is a funny market. Customers like to be able to actually access
data they may have archived years ago, which typically requires them to
use the same software to access that data. If that software uses the
MODE SELECT method of changing partitions, and the market is big
enough...

<Joe> 

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.

<Joe> 
Yes, this can have several undesired side effects. However, I don't
beleive that they can lead to the level of data loss, for several
reasons. Most importantly, I cannot envision a scenario whereby any
changes to the data compression page would cause the current position to
be changed out from underneath an initiator. Therefore, it could not
cause writes over previously written sections of tape, without the
initiator being aware of the situation.

</Joe> 

In your scenario below,  will not a Unit Attention condition occur
indicating a mode parameters have changed? 

<Joe> 
I do not believe that there is any requirement to generate a UA upon
PLOGI. I rather think that may confuse many initiators. Likewise, I know
of no requirement for UA upon MODE SELECT.

</Joe> 

Also, does the tape drive reposition to partition 0 by itself? 

<Joe> 
Seems to me that FCP-2 table 4 mandates that PLOGI shall cause the
current position to be changed to LBA 0 of the partition specified in
the last received Device Configuration page.

</Joe> 

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
<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_001_01C1C702.C30AC710
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: Dave Peterson [mailto:dap at cisco.com] 
Sent: Friday, March 08, 2002 1:50 PM 
To: JoeBre at exabyte.com; rsnively at brocade.com; = t10 at t10.org 
Subject: RE: Clearing effects of logouts on = different protocols 
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. <Joe> 
I don't know how an application client = (driver/application) in one initiator would have any idea that some = other initiator (or other FC-capable thingy -- not necessarily SCSI) = performed a PLOGI to the tape device (target it was communicating = with). As such, the OS tape driver/application does not know what is = going on. The state of the device has been changed out from underneath = it. Reservations, whether classic or persistent, do not prevent this = from happening, as it can be the PLOGI that caused mandated state = changes. </Joe> 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. <Joe> 
Agreed. Perhaps we can do this for SSC-2. SSC(-1) = devices will still be problematic, as will disk devices (geometry = pages). I would not be surprised if other device models would exhibit = similar problems, due to the clearing effects of PLOGI upon mode pages, = if examined. </Joe> One issue with using mode select to change the = partition is that some devices do not allow a change if not at = BOP. <Joe> 
That may be, but I see nothing in SSC that mandates = that partition can be changed only when positioned at BOP. There = certainly exist implementations in the field that do not have this = restriction. Even so, I'm not sure that has any bearing on the = identified problem. </Joe> (BTW, the mode select method to change partitions has = since been obsoleted in favor of LOCATE.) <Joe> 
As well it should. We probably never should have had = two ways to change partitions to begin with. We do, we learn, we grow. = Be that as it may, tape is a funny market. Customers like to be able to = actually access data they may have archived years ago, which typically = requires them to use the same software to access that data. If that = software uses the MODE SELECT method of changing partitions, and the = market is big enough... <Joe> 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. <Joe> 
Yes, this can have several undesired side effects. = However, I don't beleive that they can lead to the level of data loss, = for several reasons. Most importantly, I cannot envision a scenario = whereby any changes to the data compression page would cause the = current position to be changed out from underneath an initiator. = Therefore, it could not cause writes over previously written sections = of tape, without the initiator being aware of the situation. </Joe> In your scenario below,  will not a Unit = Attention condition occur indicating a mode parameters have = changed? <Joe> 
I do not believe that there is any requirement to = generate a UA upon PLOGI. I rather think that may confuse many = initiators. Likewise, I know of no requirement for UA upon MODE = SELECT. </Joe> Also, does the tape drive reposition to partition 0 = by itself? <Joe> 
Seems to me that FCP-2 table 4 mandates that PLOGI = shall cause the current position to be changed to LBA 0 of the = partition specified in the last received Device Configuration = page. </Joe> 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) foll= owing 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_01C1C702.C30AC710--




More information about the T10 mailing list