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

Gene Milligan Gene_Milligan at notes.seagate.com
Mon Jul 11 10:12:21 PDT 1994

>application clients on the initiator
 Sound painful. I suggest "initiator application clients".
>must ensure
 "shall ensure"
>initiator with the reservation is able to access the reserved media
 What did you have in mind regarding the initiator's ability?
> 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."
>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.
>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.
>a system is integrated with more than one initiator,
 What does that mean in a less obtuse description?
>there must be agreement
 there shall be an agreement
> 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.
> 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.
>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 RELEASE(10) command must be used.
  the RELEASE(10) command shall be used.
>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 ...".
>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 accepted?
 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.
>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.
>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.
 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
Gene Milligan
Gene Milligan -- Gene_Milligan at notes.seagate.com
Seagate Technology   -   920 Disc Drive   -   Scotts Valley, CA 95066 USA
Main Phone 408-438-6550   -   Email Problems postmaster at notes.seagate.com
Technical Support: BBS 408-438-8771  Fax 408-438-8137  Voice 408-438-8222  

### OGATE Version 8 message trace and attachment information:
### MsgFileName: m:\mgate\outbound\12.MSG
### Org Date:    07-11-94 09:54:01 AM
### From:        Gene Milligan at SEAGATE
### To:          scsi @ wichitaks.ncr.com @ internet
### Subject:     Re: 94-106r1 -- Reserve & Release in SCSI-3 Primary Commands
### Attachments: none

More information about the T10 mailing list