Request for SPC-3 PR question clarification.

Ulrich, David dulrich at lsil.com
Mon Nov 17 11:12:40 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Ulrich, David" <dulrich at lsil.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_01C3AD3E.AB003140
Content-Type: text/plain;
	charset="iso-8859-1"

 
-----Original Message-----
From: Ulrich, David 
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 
 


------_=_NextPart_001_01C3AD3E.AB003140
Content-Type: text/html;
	charset="iso-8859-1"

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

 Message  
 -----Original Message-----
From: Ulrich, David 
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 
 


------_=_NextPart_001_01C3AD3E.AB003140--




More information about the T10 mailing list