SPC-3 PR Question

Charles Binford Charles.Binford at sun.com
Tue Nov 18 12:47:55 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* Charles Binford <Charles.Binford at Sun.COM>
*
This is a multi-part message in MIME format.

--Boundary_(ID_eEWkYS9VqopJSop2l2mrWQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

George, sounds like I need to bring in a proposal.
 
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.
 
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 
Sun Microsystems 
316.315.0382 x222 

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



Charles. 

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. 

The words in the standard state: 

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



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> 
Sent by: owner-t10 at t10.org 


11/18/2003 11:18 AM 


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




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. 
  
Consider the following case: 
- Initiator A, registered with Key=x 
- Initiator B, registered with Key=x (same as Initiator A) 
- Initiator C, registered with Key=y 
- Initiator C currently has a Reservation 
  
- network communication path between Initiator A and B fails, so they
both assume the other is dead 
- Initiator 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 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. 
  
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. 
  
Charles Binford 
Sun Microsystems 
316.315.0382 x222 
-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com] 
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. 

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. 

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> 
Sent by: Charles.Binford at Sun.COM 


11/17/2003 01:25 PM 

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




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. 
 
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... 
 
  

Charles Binford 
Sun Microsystems 
316.315.0382 x222 


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

Hi Charles, 
 
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: 
 
"If there is a persistent reservation and if the SERVICE ACTION
RESERVATION KEY field does not identify a persistent 
reservation holder the device server shall perform a preempt by doing
the following in an uninterrupted series of 
actions: 
 
a) Remove the registration for the I_T nexus or I_T nexuses identified
by the SERVICE ACTION RESERVATION KEY field; 
b) Ignore the contents of the SCOPE and TYPE fields; 
c) Process tasks as defined in 5.6.1; and 
d) Establish a unit attention condition for any initiator port
associated with an I_T nexus that lost its registration 
other than the initiator port that sent the PERSISTENT RESERVE OUT
command. The sense key 
shall be set to UNIT ATTENTION and the additional sense code shall be
set to REGISTRATIONS 
PREEMPTED." 
 
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. 
 
The flowchart in section 5.7.6.2.4.1 doesn't shed any additional light
on this question either. 
 
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. 
  
Best Regards, 


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


LSI Logic Storage Systems 
AT THE HEART OF INFORMATION 



-----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 


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. 


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. 


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. 


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. 
 
Thanks, 
 
Charles Binford 
Sun Microsystems 
316.315.0382 x222 
 







--Boundary_(ID_eEWkYS9VqopJSop2l2mrWQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

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

 Message George, sounds like I need to bring in a proposal.
  
 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.
  
 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 
Sun Microsystems 
316.315.0382 x222 

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



Charles. 

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. 

The words in the standard state: 

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



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> 
Sent by: owner-t10 at t10.org 11/18/2003 11:18 AM 
        
        To:        t10 at t10.org 
        cc:         
        Subject:        RE: SPC-3 PR Question 



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. 
  
Consider the following case: 
- Initiator A, registered with Key=x 
- Initiator B, registered with Key=x (same as Initiator A) 
- Initiator C, registered with Key=y 
- Initiator C currently has a Reservation 
  
- network communication path between Initiator A and B fails, so they both assume the other is dead 
- Initiator 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 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. 
  
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. 
  
Charles Binford 
Sun Microsystems 
316.315.0382 x222 
-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com] 
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. 

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. 

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



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. 
 
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... 
 
  Charles Binford 
Sun Microsystems 
316.315.0382 x222 -----Original Message-----
From: Ulrich, David [mailto:dulrich at lsil.com] 
Sent: Monday, November 17, 2003 1:07 PM
To: 'Charles Binford'
Subject: RE: SPC-3 PR Question

Hi Charles, 
 
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: 
 
"If there is a persistent reservation and if the SERVICE ACTION RESERVATION KEY field does not identify a persistent 
reservation holder the device server shall perform a preempt by doing the following in an uninterrupted series of 
actions: 
 
a) Remove the registration for the I_T nexus or I_T nexuses identified by the SERVICE ACTION RESERVATION KEY field; 
b) Ignore the contents of the SCOPE and TYPE fields; 
c) Process tasks as defined in 5.6.1; and 
d) Establish a unit attention condition for any initiator port associated with an I_T nexus that lost its registration 
other than the initiator port that sent the PERSISTENT RESERVE OUT command. The sense key 
shall be set to UNIT ATTENTION and the additional sense code shall be set to REGISTRATIONS 
PREEMPTED." 
 
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. 
 
The flowchart in section 5.7.6.2.4.1 doesn't shed any additional light on this question either. 
 
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. 
  
Best Regards, David Ulrich 
Staff Software Engineer 
LSI Logic Storage Systems 
3718 N. Rock Road 
(316) 636-8871 
david.ulrich at lsil.com 
www.lsilogicstorage.com LSI Logic Storage Systems 
AT THE HEART OF INFORMATION 
-----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 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. 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. 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. 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. 
 
Thanks, 
 
Charles Binford 
Sun Microsystems 
316.315.0382 x222 
 
 

--Boundary_(ID_eEWkYS9VqopJSop2l2mrWQ)--




More information about the T10 mailing list