94-106r1 -- Reserve & Release in SCSI-3 Primary Commands

Ralph Weber -- VMS -- ZKO3-4/U14 weber at star.enet.dec.com
Sun Jul 31 04:25:19 PDT 1994

A review of the 94-106r1 document was held at the July X3T10 working group
meeting.  Gene was not present.  The following summarizes the working group's
(or my) response to Gene's comments.

>application clients on the initiator
Sound painful. I suggest "initiator application clients".

....  The working group changed this sentence to: "An application client uses
....  reservations to gain a level of exclusivity in access to all or part of
....  the medium for it's initiator."
>must ensure
"shall ensure"

....  Done.
>initiator with the reservation is able to access the reserved media
What did you have in mind regarding the initiator's ability?

....  These are the words from SCSI-2.  The working group's opinion about
....  these word was, "If it ain't broke, don't fix it."
> a SCSI device
Thank you!
>receives a command from an application client on an initiator other than the
one holding the reservation.
"One" can be confused between application clients and initiators. The
confusion would be eliminated by "receives a command from an initiator other
than the one holding the reservation."

....  The working group liked your words.  R2 will include this change.
>Commands that affect overall device status shall generate a reservation
>conflict, if the device server receives them while an extent reservation 
>is present.
This is incorrect on several basis. I assume status is referring to
configuration and/or parameters. but I should not have to assume what it
refers to. A reservation conflict should not occur if the command is from the
initiator with the reservation. It should also not occur if configurations
and/or parameters are maintained on a per initiator basis. If status refers to
commands please say so.

....  The working group decided that:
....  1) this clause should contain the fundamental rules upon which
....  individual commands can base their reservations policy, and
....  2) each command description clause shall contain a description of that
....  command's reservations handling rules.
....  The R2 document will be revised to reflect the working group's decision.
>WRITE BUFFER commands shall not be affected by extent reservations.
I think I agree that you could conclude this from SCSI-2. However I think
there are aspects of  READ BUFFER, and WRITE BUFFER commands that may  be
affected by extent reservations.

....  I will propose specific words for READ BUFFER and WRITE BUFFER in R2.
>a system is integrated with more than one initiator,
What does that mean in a less obtuse description?

....  The working group changed this to: "a system contains more than one
....  initiator,".
>there must be agreement
 there shall be an agreement

....  The working group changed this to: "there should be an agreement".  As a
....  developer of initiator programs, I support the working group decision. 
....  If the "should" is changed to a "shall", I think the host obligations
....  would go beyond those normally set by SCSI.

> otherwise, an initiator may be locked out of access to a target in the
> middle of an operation.
With a firm requirement the violation consequences and the subsequent example
can be deleted.

....  Since there is no firm requirement, the consequences still must be
....  described.
> x.x.x Extent release (Optional)
This section is OK.  However it repeats the perverse nature of SCSI to list
errors first and success last.  Being of a more positive temperament, I would
reverse the order of the paragraphs.

....  The working group agreed with this change.
>If the third-party (3rdPty) bit is zero, then a third-party release is not
> requested.  If the 3rdPty bit is one then the device server shall release
>the specified logical unit or extents, but only if the initiator ID for the
>application client, 3rdPty bit, and Third party device ID are identical when
>compared to the RESERVE command that established the reservation.
This agrees with SCSI-2 and is OK but I suggest:  "shall release the specified
logical unit or extents if the initiator ID for the application client, 3rdPty
bit, and Third party device ID are identical when compared to the RESERVE
command that established the reservation. If the initiator is not the one that
made the reservation, the logical unit shall ??????".

....  The correct additional sentence would be: "If the initiator is not the
....  one that made the reservation the logical unit shall not change any
....  reservations and shall return GOOD status."  The working group felt that
....  this is covered sufficiently elsewhere.  The additional text will not be
....  added.
> the RELEASE(10) command must be used.
"the RELEASE(10) command shall be used."

....  This change shall be made.
>The third-party device can issue MODE SENSE and MODE SELECT commands to query
>and modify the mode parameters.
Attempts should be made to make the requirements clear and the notes deleted.
Failing that "The third-party device may issue ...".

....  The sentence will be changed to, "The third-party device may issue ...".
>If the Third party device ID value associated with the reservation release is
>smaller than 255, the LongID bit may be zero and the ID value sent in the
The LongID was not included in the version of the RELEASE(10) and RESERVE(10)
commands accepted into SCSI-3. Where did it come from and when was it

....  The purpose of 94-106r1 is to define and gain acceptance for the LongID
....  bit.  LongID will be accepted into SCSI-3 when (or if) 94-106rX is
....  approved.
I do not recall the arguments vividly.  But there was a case made for allowing
the removal through a reservation for physical security and/or restoration
reasons.  I do not object to revisiting the tradeoffs but object to it being
removed just for editorial reasons.  I acknowledge that you have flagged the
issue.  I think it should be mad a specific agenda topic so the impacted
parties have the opportunity to notice.

....  I proposed deleting the PREVENT ALLOW MEDIUM REMOVAL command from this
....  list because the PREVENT ALLOW MEDIUM REMOVAL command is not defined in
....  the SPC.  I never intended any change in the behavior of the PREVENT
....  ALLOW MEDIUM REMOVAL command.  With the working group decision that
....  every command definition clause contain a definition of that command's
....  response to reservations, I believe that the whole list will disappear.
>The individual command standards (SBC, SSC, SGC, etc.) may define other
>specific commands that are permissable while there is a reservation from
>other initiator.
Perhaps appropriate for the minutes but not for the standard. If they do this
fact should be flagged in a more prominent location of the RESERVE/RELEASE
pairs and in the normative reference section.  Alternatively if they do and it
is a don't care for all other devices, it might be acceptable to be silent on
the subject except within the specific device type.

....  I think that this is covered by the working group decision to require a
....  discussion of reservations handling in every command definition clause.
>If an application client attempts a command to a logical block that
>has been reserved and that access is prohibited by the reservation,
>the command shall not be performed and the command shall be terminated
>with a RESERVATION CONFLICT status.  If a reservation conflict
>precludes any part of the command, none of the command shall be
>performed.  Clause (?.?) and the various command standards (SBC, SSC,
>SGC, etc.) define additional rules for interactions between extent
>reservations and specific commands.

If a reservation conflict precludes any part of the command, none of the
command shall be performed.  This seems whole redundant to the first sentence.
The redundancy suggests you do not really mean the first requirement.  I
presume if you were thinking in terms of an I/O Process there is an unsolvable
conundrum if an initiator mishandles linked commands.

....  Actually, I was not thinking of any particular case.  I simply copied
....  the words out of SCSI-2 and changed "initiator" to "application client." 
....  I forgot to ask the working group about this particular paragraph. 
....  However, their "if it ain't broke, don't fix it" attitude suggests that
....  this paragraph should not be changed.
There was a "^Z" at the end of your message shortly after (two sentences)
Table a9. I don't know if this was an end of message mark or an unexpected

....  That was an artifact of Kermit.  If I am equally sloppy with this
....  message, there will be another ^Z at it's end.



More information about the T10 mailing list