SPC-3 PR Question

Elliott, Robert (Server Storage) elliott at hp.com
Tue Nov 18 16:17:58 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C3AE32.95D54E87
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think I have to weigh in on the "don't change it" side.
=20
When a reservation does exist, preempt:
a) wipes out all the registrations with the specified key;
b) creates a new reservation.  The I_T nexus for the new reservation
needs to be registered or this would fundamentally break PR.
=20
When a reservation does not exist, preempt still does as much as
possible.  It wipes out all registrations with the specified key.  It
does not establish a new reservation.  The RESERVE service action is
intended for that.  Having this definition is mainly useful for PREEMPT
AND ABORT, as it provides the only way to abort tasks for all I_T
nexuses with the specified key.
=20
When an I_T nexus is used to preempt itself (reservation key =3D =
service
action reservation key), it still tries to do as much as possible in
both situations.
=20
When a reservation does exist, it wipes out all the registrations =
except
its own, because it is the owner of the new reservation and has to
remain registered.  It doesn't have to give itself a unit attention
(which the last paragraph in 5.6.2.7.4.4 is trying to say).
=20
When a reservation does not exist, it wipes out all the registrations.
It does not have to leave a registration pending for itself, because
it's not going to be left holding a new reservation, so it wipes out =
its
own registration too.  It doesn't have to give itself a unit attention
(which the last paragraph in 5.6.2.7.4.4 is trying to say).
=20
In your example case with initiators A and B, the proposed Specify
Initiator Ports feature for PREEMPT and PREEMPT AND ABORT (see 03-337)
would be the way to let initiator A preempt initiator B's I/Os (and =
vice
versa) when they are using the same key.  Without that feature, they
have to expect their own I/Os to be wiped out too.
=20
--=20
Rob Elliott, elliott at hp.com=20
Hewlett-Packard Industry Standard Server Storage Advanced Technology=20
https://ecardfile.com/id/RobElliott
<https://ecardfile.com/id/RobElliott> =20


-----Original Message-----
From: Charles Binford [mailto:Charles.Binford at sun.com]=20
Sent: Tuesday, November 18, 2003 2:48 PM
To: t10 at t10.org
Subject: RE: SPC-3 PR Question


George, sounds like I need to bring in a proposal.
=20
All,  I'd appreciate feedback sooner than later if a proposal to make
the two cases of "Preempt with your own key" behave the same way is
going to break anyone's implementation.
=20
To be more specific, my proposal will be along the lines of changing =
the
following paragraph in 5.6.2.7.4.4 from

It is not an error for a PERSISTENT RESERVE OUT with a PREEMPT service
action or a PREEMPT AND ABORT service action to set the RESERVATION KEY
and the SERVICE ACTION RESERVATION KEY to the same value, however, no
unit attention condition is established for the initiator port that =
sent
the PERSISTENT RESERVE OUT

to


It is not an error for a PERSISTENT RESERVE OUT with a PREEMPT service
action or a PREEMPT AND ABORT service action to set the RESERVATION KEY
and the SERVICE ACTION RESERVATION KEY to the same value, however, for
the initiator port that sent the PERSISTENT RESERVE OUT the =
registration
is maintained and no unit attention condition is established.

Charles Binford=20
Sun Microsystems=20
316.315.0382 x222=20

-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com]=20
Sent: Tuesday, November 18, 2003 1:34 PM
To: Charles Binford
Cc: t10 at t10.org
Subject: RE: SPC-3 PR Question



Charles.=20

I do not agree that the standard is unclear on this issue. It clearly
states, with no exceptions, that the registration is cleared. The fact
that another action has a clearly defined behavior that is different =
and
happens to use the Preempt service action makes no difference. That's
not to say there is no issue with the way it is currently defined, but
that's a different topic and should be handled with a proposal. But if
you want to change the currently defined behavior don't claim the
current behavior is unclear.=20

The words in the standard state:=20

If there is a persistent reservation and if the SERVICE ACTION
RESERVATION KEY field does not identify a persistent=20
reservation holder the device server shall perform a preempt by doing
the following in an uninterrupted series of=20
actions:=20
a) Remove the registration for the I_T nexus or I_T nexuses identified
by the SERVICE ACTION RESERVATION=20
KEY field;=20
b) Ignore the contents of the SCOPE and TYPE fields;=20
c) Process tasks as defined in 5.6.1; and=20
d) Establish a unit attention condition for any initiator port
associated with an I_T nexus that lost its registration=20
other than the initiator port that sent the PERSISTENT RESERVE OUT
command. The sense key=20
shall be set to UNIT ATTENTION and the additional sense code shall be
set to REGISTRATIONS=20
PREEMPTED.=20



Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880





	Charles Binford <Charles.Binford at sun.com>=20
Sent by: owner-t10 at t10.org=20


11/18/2003 11:18 AM=20


       =20
        To:        t10 at t10.org=20
        cc:        =20
        Subject:        RE: SPC-3 PR Question=20
=09



George, we agree there is an issue!  However, I would argue that the
lack of the registration removal exception for the sending initiator =
was
a corner case the standard covered in case 1, but failed to mention in
the other case.  Thus leaving it up for implementers to "interpret".
Further, I believe saying the sending initiator's registration is
removed via Preempt BREAKS PR.=20
 =20
Consider the following case:=20
- Initiator A, registered with Key=3Dx=20
- Initiator B, registered with Key=3Dx (same as Initiator A)=20
- Initiator C, registered with Key=3Dy=20
- Initiator C currently has a Reservation=20
 =20
- network communication path between Initiator A and B fails, so they
both assume the other is dead=20
- Initiator A and B both send down PREEMPT to lock the other "failed"
initiator out=20
 =20
Now if one interprets the standard to say both A and B have their keys
removed, then BOTH ARE LOCKED OUT.  If one interprets the standard to
say the "don't preempt yourself" exception should also apply to this
case, then preempt works as expected, one initiator wins, one looses,
and the system works as expected.=20
 =20
Note, if Initiator A or B happened to have had the Reservation then
we're clearly in the case where the standard states the "don't preempt
yourself" exception.  I don't think the current ownership of the
Reservation should drastically change the rules of how the A and B
preempt is processed for removing Registrations.=20
 =20
Charles Binford=20
Sun Microsystems=20
316.315.0382 x222=20
-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com]=20
Sent: Monday, November 17, 2003 2:20 PM
To: Charles Binford
Cc: 'Ulrich, David'; t10 at t10.org
Subject: RE: SPC-3 PR Question


Charles.=20

The wording in section 5.6.2.7.4.4 and in the flowchart (as soon as it
is fixed per 03-253) indicates that the registration is removed. This =
is
no exception stated for the case you describe where the key that is =
sent
on a preempt is the same as the key for the I_T nexus receiving the PR
command.=20

I do agree that this is an interesting anomaly in that, if the
reservation was held by the I_T nexus being preempted both the
reservation and registration remain but if there is no reservation held
by the I_T nexus being preempted then the registration is removed.
However, that's the way it's described and presumably implemented. So a
few words making that clear may be in order.

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880




	Charles Binford <Charles.Binford at Sun.COM>=20
Sent by: Charles.Binford at Sun.COM=20


11/17/2003 01:25 PM=20

       =20
       To:        "'Ulrich, David'" <dulrich at lsil.com>=20
       cc:        George Penokie/Rochester/IBM at IBMUS=20
       Subject:        RE: SPC-3 PR Question =09




David,  George had sent me direct email asking whether or not I got my
answer.  I'm cc'ing him on this as an example of someone else who finds
this scenario ambiguous in the current spec.=20
=20
George,  I'm thinking we should add a sentence or two to SPC-3 in this
clause to clarify things.  Your comments on the subject welcome...=20
=20
 =20

Charles Binford=20
Sun Microsystems=20
316.315.0382 x222=20


-----Original Message-----
From: Ulrich, David [mailto:dulrich at lsil.com]=20
Sent: Monday, November 17, 2003 1:07 PM
To: 'Charles Binford'
Subject: RE: SPC-3 PR Question

Hi Charles,=20
=20
After further review I think a definitive answer to your question is in
order.  The wording of 5.6.2.7.4.4 as follows:=20
=20
"If there is a persistent reservation and if the SERVICE ACTION
RESERVATION KEY field does not identify a persistent=20
reservation holder the device server shall perform a preempt by doing
the following in an uninterrupted series of=20
actions:=20
=20
a) Remove the registration for the I_T nexus or I_T nexuses identified
by the SERVICE ACTION RESERVATION KEY field;=20
b) Ignore the contents of the SCOPE and TYPE fields;=20
c) Process tasks as defined in 5.6.1; and=20
d) Establish a unit attention condition for any initiator port
associated with an I_T nexus that lost its registration=20
other than the initiator port that sent the PERSISTENT RESERVE OUT
command. The sense key=20
shall be set to UNIT ATTENTION and the additional sense code shall be
set to REGISTRATIONS=20
PREEMPTED."=20
=20
doesn't say anything about excluding the preempting initiator or
establishing a registration for the preempting initiator after removing
its registration.  The implication of step d could be construed that =
the
registration was removed and so the specific instruction to exclude it
|from a UA is required.=20
=20
The flowchart in section 5.7.6.2.4.1 doesn't shed any additional light
on this question either.=20
=20
As the sections in question stand now, I think they may be construed to
mean that it is possible to remove your own key with a preempt service
action.  If this isn't the intent then I think specific wording should
be introduced for clarification.=20
 =20
Best Regards,=20


David Ulrich=20
Staff Software Engineer=20
LSI Logic Storage Systems=20
3718 N. Rock Road=20
(316) 636-8871=20
david.ulrich at lsil.com=20
www.lsilogicstorage.com=20


LSI Logic Storage Systems=20
AT THE HEART OF INFORMATION=20



-----Original Message-----
From: Charles Binford [mailto:Charles.Binford at sun.com]
Sent: Friday, November 14, 2003 1:24 PM
To: 'T10 Reflector'
Cc: Henderson, Steve
Subject: SPC-3 PR Question=20


All, I have a question on whether or not a Registration is removed when
an Initiator uses Preempt on his own Key.  I'm reading SPC-3 Revision
15.  In the section where Preempt Key matches a reservation holder the
text clearly says the registration is not cleared.=20


5.6.2.7.4.3 Preempting persistent reservations and registration =
handling
...
If the SERVICE ACTION RESERVATION KEY identifies a persistent
reservation holder....
...
A PERSISTENT RESERVE OUT with a PREEMPT service action or a PREEMPT AND
ABORT service action with the SERVICE ACTION RESERVATION KEY value =
equal
to the persistent reservation holder's reservation key is not an error.
In that case the device server shall establish the new persistent
reservation and maintain the registration.=20


However, in the next section where the Preempt Key does NOT match the
persistent reservation holder the text merely says "It is not an =
error".



5.6.2.7.4.4 Removing registrations
...
If there is a persistent reservation and if the SERVICE ACTION
RESERVATION KEY field does not identify a persistent reservation
holder....
...
It is not an error for a PERSISTENT RESERVE OUT with a PREEMPT service
action or a PREEMPT AND ABORT service action to set the RESERVATION KEY
and the SERVICE ACTION RESERVATION KEY to the same value, however, no
unit attention condition is established for the initiator port that =
sent
the PERSISTENT RESERVE OUT.=20


My assumption is that one can never remove your own registration with a
preempt (you register with a zero key), but I'm having trouble finding
words that clearly back up that statement for all cases.=20
=20
Thanks,=20
=20
Charles Binford=20
Sun Microsystems=20
316.315.0382 x222=20
=20







------_=_NextPart_001_01C3AE32.95D54E87
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

Message I=20 think I have to weigh in on the "don't change it" = side.
  
 When a=20 reservation does exist, preempt:
 a)=20 wipes out all the registrations with the specified = key;
 b)=20 creates a new reservation.  The I_T nexus for the new reservation needs to = be=20 registered or this would fundamentally break=20 PR.

  
 When a=20 reservation does not exist, preempt still does as much as = possible.  It=20 wipes out all registrations with the specified key.  It does not = establish=20 a new reservation.  The RESERVE service action is intended for = that. =20 Having this definition is mainly useful for PREEMPT AND = ABORT, as it=20 provides the only way to abort tasks for all I_T nexuses with the = specified=20 key.
  
 When=20 an I_T nexus is used to preempt itself (reservation key =3D service = action=20 reservation key), it still tries to do as much as possible in both=20 situations.
  
 When a=20 reservation does exist, it wipes out all the registrations except its = own,=20 because it is the owner of the new reservation and has to remain=20 registered.  It doesn't have to give itself a unit attention = (which the=20 last paragraph in 5.6.2.7.4.4 is trying to say).
  
 When a=20 reservation does not exist, it wipes out all the registrations.  = It does=20 not have to leave a registration pending for itself, because it's not = going to=20 be left holding a new reservation, so it wipes out its own registration = too.  It doesn't have to give itself a unit attention (which the = last=20 paragraph in 5.6.2.7.4.4 is trying to say).
  
 In=20 your example case with initiators A and B, the proposed Specify = Initiator Ports=20 feature for PREEMPT and PREEMPT AND ABORT (see 03-337) would = be the=20 way to let initiator A preempt initiator B's I/Os (and vice versa) when = they are=20 using the same key.  Without that feature, they have to expect = their own=20 I/Os to be wiped out too.
  
 -- = 
Rob Elliott, = elliott at hp.com=20 
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology 
https://ecardfile.com/id/Ro= bElliott=20 


-----Original Message-----
From: = Charles Binford=20 [mailto:Charles.Binford at sun.com] 
Sent: Tuesday, November = 18, 2003=20 2:48 PM
To: t10 at t10.org
Subject: RE: SPC-3 PR=20 Question


 George, sounds like I need to bring in a = proposal.
  
 All,  I'd appreciate feedback sooner than later if a = proposal to=20 make the two cases of "Preempt with your own key" behave the same way = is going=20 to break anyone's implementation.
  
 To=20 be more specific, my proposal will be along the lines of changing the = following paragraph in 5.6.2.7.4.4 from
 It is not an error for a PERSISTENT RESERVE OUT with a PREEMPT = service=20 action or a PREEMPT AND ABORT service action to set the RESERVATION = KEY and=20 the SERVICE ACTION RESERVATION KEY to the same value, however, no = unit=20 attention condition is established for the initiator port that sent = the=20 PERSISTENT RESERVE OUT
 to
 It is not an error for a PERSISTENT RESERVE OUT with a PREEMPT = service=20 action or a PREEMPT AND ABORT service action to set the RESERVATION = KEY and=20 the SERVICE ACTION RESERVATION KEY to the same value, however, = for the initiator port that sent the PERSISTENT = RESERVE=20 OUT the registration is maintained = and=20 no unit attention condition is established.

 Charles Binford = 
Sun Microsystems 
316.315.0382 x222 

-----Original Message-----
From: = George Penokie=20 [mailto:gop at us.ibm.com] 
Sent: Tuesday, November 18, 2003 = 1:34=20 PM
To: Charles Binford
Cc:=20 t10 at t10.org
Subject: RE: SPC-3 PR=20 Question



Charles. 

I = do not agree=20 that the standard is unclear on this issue. It clearly states, with = no=20 exceptions, that the registration is cleared. The fact that another = action=20 has a clearly defined behavior that is different and happens to use = the=20 Preempt service action makes no difference. That's not to say there = is no=20 issue with the way it is currently defined, but that's a different = topic and=20 should be handled with a proposal. But if you want to change the = currently=20 defined behavior don't claim the current behavior is = unclear.=20 

The words in the standard = state:=20 

If there is a persistent = reservation=20 and if the SERVICE ACTION RESERVATION KEY field does not identify a = persistent 
reservation = holder the=20 device server shall perform a preempt by doing the following in an=20 uninterrupted series of 
actions: 
a) = Remove the=20 registration for the I_T nexus or I_T nexuses identified by the = SERVICE=20 ACTION RESERVATION 
KEY = field;=20 
b) Ignore the contents of the = SCOPE and=20 TYPE fields; 
c) Process = tasks as=20 defined in 5.6.1; and 
d) Establish a=20 unit attention condition for any initiator port associated with an = I_T nexus=20 that lost its registration 
other=20 than the initiator port that sent the PERSISTENT RESERVE OUT = command. The=20 sense key 
shall be set = to UNIT=20 ATTENTION and the additional sense code shall be set to = REGISTRATIONS=20 
PREEMPTED. = 



Bye for=20 now,
George Penokie

Dept 2C6  114-2 N212
E-Mail: =  =20  gop at us.ibm.com
Internal:  553-5208
External: = 507-253-5208=20   FAX: 507-253-2880




 Charles Binford=20 <Charles.Binford at sun.com> 
Sent by: owner-t10 at t10.org=20 11/18/2003 11:18 = AM 
       =20 
    =    =20 To:        t10 at t10.org 
        cc: =    =20     
   =20     Subject:        RE: SPC-3 = PR=20 Question = 



George, we agree there is an issue! =  However, I=20 would argue that the lack of the registration removal exception for = the=20 sending initiator was a corner case the standard covered in case 1, = but=20 failed to mention in the other case.  Thus leaving it up for=20 implementers to "interpret".  Further, I believe saying the = sending=20 initiator's registration is removed via Preempt BREAKS PR. = 
  
Consider the=20 following case: 
-=20 Initiator A, registered with Key=3Dx 
- Initiator B, registered with Key=3Dx = (same as Initiator=20 A) 
- = Initiator C,=20 registered with Key=3Dy 
-=20 Initiator C currently has a Reservation 
  
- network=20 communication path between Initiator A and B fails, so they both = assume the=20 other is dead 
- Initiator=20 A and B both send down PREEMPT to lock the other "failed" initiator = out 
  
Now if one interprets the standard to say = both A and B=20 have their keys removed, then BOTH ARE LOCKED OUT.  If one = interprets=20 the standard to say the "don't preempt yourself" exception should = also apply=20 to this case, then preempt works as expected, one initiator wins, = one=20 looses, and the system works as expected. 
  
Note, if=20 Initiator A or B happened to have had the Reservation then we're = clearly in=20 the case where the standard states the "don't preempt yourself" = exception.=20  I don't think the current ownership of the Reservation should = drastically change the rules of how the A and B preempt is = processed for=20 removing Registrations. 
  = 
Charles Binford = 
Sun Microsystems = 
316.315.0382 x222 = 
-----Original Message-----
From: = George Penokie=20 [mailto:gop at us.ibm.com] 
Sent: Monday, November 17, 2003 = 2:20=20 PM
To: Charles Binford
Cc: 'Ulrich, David';=20 t10 at t10.org
Subject: RE: SPC-3 PR = Question


Charles. = 

The wording in section 5.6.2.7.4.4 = and in the=20 flowchart (as soon as it is fixed per 03-253) indicates that the=20 registration is removed. This is no exception stated for the case = you=20 describe where the key that is sent on a preempt is the same as the = key for=20 the I_T nexus receiving the PR command. 

I do agree that this is an = interesting anomaly in=20 that, if the reservation was held by the I_T nexus being preempted = both the=20 reservation and registration remain but if there is no reservation = held by=20 the I_T nexus being preempted then the registration is removed. = However,=20 that's the way it's described and presumably implemented. So a few = words=20 making that clear may be in order.

Bye for now,
George=20 Penokie

Dept 2C6  114-2 N212
E-Mail:  =20  gop at us.ibm.com
Internal:  553-5208
External: = 507-253-5208=20   FAX: 507-253-2880



 Charles = Binford=20 <Charles.Binford at Sun.COM> = 
Sent by:=20 Charles.Binford at Sun.COM 11/17/2003 01:25 = PM     =    =20 
    =    To:=20        "'Ulrich, David'"=20 <dulrich at lsil.com> 
       cc: =  =20      George = Penokie/Rochester/IBM at IBMUS 
  =    =20  Subject:        RE: SPC-3 PR=20 Question = 



David,=20  George had sent me direct email asking whether or not I got = my answer.=20  I'm cc'ing him on this as an example of someone else who = finds this=20 scenario ambiguous in the current spec.=20 
 
George,=20  I'm thinking we should add a sentence or two to SPC-3 in this = clause=20 to clarify things.  Your comments on the subject = welcome... 
 
 =20 Charles Binford 
Sun Microsystems = 
316.315.0382 x222 = -----Original = Message-----
From:=20 Ulrich, David [mailto:dulrich at lsil.com] 
Sent: Monday, = November=20 17, 2003 1:07 PM
To: 'Charles Binford'
Subject: = RE:=20 SPC-3 PR Question

Hi Charles, = 
 
After further review I think a definitive = answer to=20 your question is in order.  The wording of 5.6.2.7.4.4 as=20 follows: 
 
"If there is=20 a persistent reservation and if the SERVICE ACTION RESERVATION KEY = field=20 does not identify a persistent 
reservation holder the device server shall perform a = preempt by=20 doing the following in an uninterrupted series of=20 
actions: = 
 
a) Remove the registration for the I_T nexus or I_T = nexuses=20 identified by the SERVICE ACTION RESERVATION KEY field;=20 
b) Ignore the contents of the SCOPE and = TYPE=20 fields; 
c) Process = tasks as=20 defined in 5.6.1; and 
d)=20 Establish a unit attention condition for any initiator port = associated with=20 an I_T nexus that lost its registration = 
other than the initiator port that sent the PERSISTENT = RESERVE=20 OUT command. The sense key 
shall=20 be set to UNIT ATTENTION and the additional sense code shall be set = to=20 REGISTRATIONS 
PREEMPTED." = 
 
doesn't say anything about excluding the = preempting=20 initiator or establishing a registration for the preempting = initiator after=20 removing its registration.  The implication of step d could be = construed that the registration was removed and so the specific = instruction=20 to exclude it from a UA is required.=20 
 
The = flowchart in=20 section 5.7.6.2.4.1 doesn't shed any additional light on this = question=20 either. 
 
As the sections in question stand now, I think they = may be=20 construed to mean that it is possible to remove your own key = with a=20 preempt service action.  If this isn't the intent then I think = specific=20 wording should be introduced for clarification.=20 
  
Best = Regards,=20 David = Ulrich 
Staff Software Engineer 
LSI Logic Storage Systems 
3718 N.=20 Rock Road = 
(316) = 636-8871 
david.ulrich at lsil.com 
www.lsilogicstorage.com=20 LSI Logic Storage=20 Systems = 
AT=20 THE HEART=20 OF INFORMATION = 
-----Original = Message-----
From:=20 Charles Binford [mailto:Charles.Binford at sun.com]
Sent: = Friday,=20 November 14, 2003 1:24 PM
To: 'T10 = Reflector'
Cc:=20 Henderson, Steve
Subject: SPC-3 PR Question=20 All, I have a question = on whether or=20 not a Registration is removed when an Initiator uses Preempt on his = own Key.=20  I'm reading SPC-3 Revision 15.  In the section where = Preempt Key=20 matches a reservation holder the text clearly says the registration = is not=20 cleared. 5.6.2.7.4.3 = Preempting persistent=20 reservations and=20 registration handling
...
If the SERVICE ACTION = RESERVATION KEY=20 identifies a persistent reservation holder....
...
A = PERSISTENT=20 RESERVE OUT with a PREEMPT service action or a PREEMPT AND ABORT = service=20 action with the SERVICE ACTION RESERVATION KEY value equal to the = persistent=20 reservation holder's reservation key is not an error. In that = case the=20 device server shall establish the new persistent reservation = and=20 maintain the registration. However, in the = next section where=20 the Preempt Key does NOT match the persistent reservation holder = the text=20 merely says "It is not an error".   = 5.6.2.7.4.4 Removing = registrations
...
If there=20 is a persistent reservation and if the SERVICE ACTION RESERVATION = KEY field=20 does not identify a persistent reservation holder....
...
It = is not an=20 error for a PERSISTENT RESERVE OUT with a PREEMPT service action or = a=20 PREEMPT AND ABORT service action to set the RESERVATION KEY and the = SERVICE=20 ACTION RESERVATION KEY to the same value, however, no unit = attention=20 condition is established for the initiator port that sent the = PERSISTENT=20 RESERVE OUT. My assumption is that = one can never=20 remove your own registration with a preempt (you register with a = zero key),=20 but I'm having trouble finding words that clearly back up that = statement for=20 all cases. 
 
Thanks, 
 
Charles Binford 
Sun Microsystems 
316.315.0382 x222 = 
 
 

------_=_NextPart_001_01C3AE32.95D54E87--




More information about the T10 mailing list