Question regarding OIR bit

Ralph Weber roweber at IEEE.org
Fri Apr 21 13:08:36 PDT 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Michael,
I believe the second sentence is meant to say "If the command should
terminate with a RESERVATION CONFLICT status, then do that."
This interpretation would make the second sentence very different from
the third.
It is possible the current second sentence wording is the result
of some working group design-on-the-fly efforts to avoid trying to
specify RESERVATION CONFLICT behavior in two places.
All the best,
.Ralph
Kevin D Butt wrote:
>
> Roger and Michael,
>
> My memory is that the OIR is set to Guarantee that when the I_T Nexus 
> on which a command is received does not hold a reservation the command 
> receives a CC telling that I_T Nexus that it does not hold a 
> reservation.	There was no other intent here than guaranteeing that 
> the initiator in question holds a reservation before allowing commands 
> to be processed.
>
> If an initiator gets a reservation conflict, he will not be allowed to 
> do I/O and knows that somebody else has the LUN reserved.  If an 
> initiator gets a "not reserved" he knows that he must reserve the LUN. 
>  I guess the question comes down to if the desired behavior of the 
> system is to make the host get "not reserved" then reservation 
> conflict when he tries to reserve.  However, if the device server is 
> supposed to respond with "not reserved" for every reservation conflict 
> eligible command then reserve would also get it and be broken.  I 
> think this dictates that the desired behavior should be:
> If a different I_T Nexus has the LUN reserved, return Reservation 
> Conflict, else if the I_T Nexus through which the command is received 
> does not hold a reservation, then return CC with "Not Reserved".
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-2869 / 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
>
>
> *"Roger Cummings" <roger_cummings at symantec.com>*
> Sent by: owner-t10 at t10.org
>
> 04/20/2006 09:47 AM
>
>	
> To
>	"Banther, Michael" <michael.banther at hp.com>
> cc
>	<t10 at t10.org>, "Casado, Reyes" <reyes.casado at hp.com>, "Greg Wheeless" > <greg_wheeless at symantec.com>
> Subject
>	RE: Question regarding OIR bit
>
>
>
>	
>
>
>
>
>
> Michael,
>  
> I've searched both my memory and my archive, and neither has been very 
> enlightening on this subject.
>  
> What I can tell you is that the current wording was not in the r0 of 
> the OIR proposal, but appeared in r1 after the initial proposal was 
> presented at the September 2003 CAP meeting. The minutes confirm that 
> changes were requested as that meeting, and my notes from then have 
> reference to needing to include the phrase "an I_T nexus not holding" 
> and define which commands the bit applies to, but that's all. After r1 
> the text is essentially unchanged until the r4 that was approved for 
> inclusion in SSC-3.
>  
> I believe that the intent here is that the 2nd and 3rd sentence 
> describe the same situation, namely that if the OIR bit is set to one, 
> and and a command is received for logical unit upon which no 
> reservation or persistent reservation exists, then the response is a 
> CHECK CONDITION with "Not Reserved".
>  
> I don't believe that your interpretation of the sentences as 
> describing different situations works, because in the first bullet the 
> response would be a Reservation Conflict, and that is not related to 
> what is being addressed in the OIR description.
>  
> Note that the second sentence only says "no reservation exists", while 
> the 3rd says "no reservation or persistent reservation exists". I 
> wonder if the wording is and attempt to cover the use of the OIR bit 
> with both SPC-2 and SPC-3 compliant devices. Sorry, that's the only 
> constructive suggestion I can make - does anybody else have other 
> ideas or memories?
>  
> Regards,
>  
>  
>  
>  
> Roger Cummings
> SYMANTEC
>  
> _roger_cummings at symantec.com_ <mailto:roger_cummings at symantec.com>
> ------------------------------------------------------------------------
>
> *From:* Banther, Michael [mailto:michael.banther at hp.com] *
> Sent:* Tuesday, April 18, 2006 12:10 PM*
> To:* Roger Cummings*
> Cc:* t10 at t10.org; Casado, Reyes*
> Subject:* Question regarding OIR bit
>
> Hi Roger,
>  
> In SSC-3r02, clause 8.3.3, the definition of the OIR bit has caused 
> some confusion here:
> If the only if reserved (OIR) bit is set to one, the device server 
> shall process a command only if a reservation (see SPC-2) or 
> persistent reservation (see SPC-3) exists that allows access via the 
> I_T nexus from which the command was received. If the OIR bit is set 
> to one and a command is received from an I_T nexus for which no 
> reservation exists, the device server shall not process the command. 
> If the OIR bit is set to one and a command is received from an I_T 
> nexus for a logical unit upon which no reservation or persistent 
> reservation exists, the device server shall terminate the command with 
> CHECK CONDITION status. The sense key shall be set to ILLEGAL REQUEST 
> and the additional sense code shall be set to NOT RESERVED.
> We're not sure whether you intended the second a third sentences above 
> to describe the same situation or two slightly different situations. 
>  I read it that these two sentences describe two different situations:
>
>     * The first sentence applies to a command received from an I_T
>	nexus when that I_T nexus does not hold a reservation (including
>	a persistent reservation) but some other I_T nexus does hold one.
>     * The second sentence applies to a command received from an I_T
>	nexus when neither that I_T nexus nor any other I_T nexus holds
>	a reservation.
>
> However it's possible to interpret that second sentence as an 
> introduction to the specifics of the third sentence, in which case 
> they refer to the same situation.  Could you please clarify the 
> intention?
>  
> Michael Banther
> Hewlett-Packard Ltd.
> Telephone +44 (117) 312-9503
>  
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list