Clearing effects of logouts on different protocols

JoeBre at exabyte.com JoeBre at exabyte.com
Wed Mar 13 10:59:38 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_01C1CAC1.3993A200
Content-Type: text/plain;
	charset="iso-8859-1"

Dave (et al) -
 
You have indeed provided me with concrete evidence that the state of the
logical unit cannot be changed 'out from underneath' the initiator
without the initiator's knowledge of this event occurring (as mistakenly
described in my scenario). My scenario is indeed flawed. If the scenario
is modified to include the mandated UA, it removes the potential for
data loss from this scenario.
 
So the situation is not nearly as dire as I had claimed earlier. I need
to apologize to all for inciting a tempest in a teapot.
 
This is not to say, however, that I believe the issue is completely
addressed. The scenario, as modified, may still result in significantly
impaired system behavior. It is unclear to me how a backup application
may be able to resume a backup that the clearing effects of PLOGI has
interrupted. I do not see how the application has any way to determine
what logical elements were successfully written to the media. If this is
indeterminate, it may have to restart the entire backup process. In the
case of a small enough average period for PLOGI events, the backup may
never complete.
 
I suppose it would be possible that the application periodically ensure
that it issues some command that causes a buffer flush, in order to
create 'known sync points' in the backup. This requirement *may* (I'm
not an application guy) render unusable existing implementations.
 
Thanx for your forbearance,
Joe Breher
Exabyte Corp

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


I'm not saying there is a requirement to send UA upon PLOGI itself.
 
Per SAM-2 clause 5.8.5 a unit attention for each initiator shall be
sent:
g) The mode parameters in effect for the initiator have been restored
|from non-volatile memory;
i) Any other event requiring the attention of the initiator.
 
FCP-2 table 4 states:
"Target mode page parameters restored from saved pages (when saved pages
are supported, or default mode page parameters when saved pages are not
supported)"
 
The intent is that the mode page parameters are restored only for the
initiator that performed the action (LOGO/PLOGI in this case).
Granted this does not help implementations that use shared mode pages,
but a unit attention should be sent anyways.
 
Dave

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of
JoeBre at exabyte.com
Sent: Friday, March 08, 2002 6:39 PM
To: dap at cisco.com; rsnively at Brocade.COM; t10 at t10.org
Subject: 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
<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_01C1CAC1.3993A200
Content-Type: text/html;
	charset="iso-8859-1"

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

RE: Clearing effects of logouts on different protocols Dave (et al) -
  
 You have indeed provided me with concrete evidence that the state of the logical unit cannot be changed 'out from underneath' the initiator without the initiator's knowledge of this event occurring (as mistakenly described in my scenario). My scenario is indeed flawed. If the scenario is modified to include the mandated UA, it removes the potential for data loss from this scenario.
  
 So the situation is not nearly as dire as I had claimed earlier. I need to apologize to all for inciting a tempest in a teapot.
  
 This is not to say, however, that I believe the issue is completely addressed. The scenario, as modified, may still result in significantly impaired system behavior. It is unclear to me how a backup application may be able to resume a backup that the clearing effects of PLOGI has interrupted. I do not see how the application has any way to determine what logical elements were successfully written to the media. If this is indeterminate, it may have to restart the entire backup process. In the case of a small enough average period for PLOGI events, the backup may never complete.
  
 I suppose it would be possible that the application periodically ensure that it issues some command that causes a buffer flush, in order to create 'known sync points' in the backup. This requirement *may* (I'm not an application guy) render unusable existing implementations.
  
 Thanx for your forbearance,
 Joe Breher
 Exabyte Corp
 -----Original Message-----
From: Dave Peterson [mailto:dap at cisco.com]
Sent: Tuesday, March 12, 2002 11:34 PM
To: JoeBre at exabyte.com; rsnively at brocade.com; t10 at t10.org
Subject: RE: Clearing effects of logouts on different protocols


 I'm not saying there is a requirement to send UA upon PLOGI itself.
  
 Per SAM-2 clause 5.8.5 a unit attention for each initiator shall be sent:
 g) The mode parameters in effect for the initiator have been restored from non-volatile memory;
 i) Any other event requiring the attention of the initiator.
  
 FCP-2 table 4 states:
 "Target mode page parameters restored from saved pages (when saved pages are supported, or default mode page parameters when saved pages are not supported)"
  
 The intent is that the mode page parameters are restored only for the initiator that performed the action (LOGO/PLOGI in this case).
 Granted this does not help implementations that use shared mode pages, but a unit attention should be sent anyways.
  
 Dave
 -----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of JoeBre at exabyte.com
Sent: Friday, March 08, 2002 6:39 PM
To: dap at cisco.com; rsnively at Brocade.COM; t10 at t10.org
Subject: 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) 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_01C1CAC1.3993A200--




More information about the T10 mailing list