Clearing effects of logouts on different protocols

Dave Peterson dap at cisco.com
Tue Mar 12 22:33:45 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_003B_01C1CA26.BC8C8BE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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



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



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

------=_NextPart_000_003B_01C1CA26.BC8C8BE0--




More information about the T10 mailing list