Resend: Change list for Persistent Reservation document
snively at scsi
snively at scsi
Thu Sep 28 10:41:40 PDT 1995
Resend for possible mailer failure, sorry for any duplicates.
The document has been transmitted in post script format to the
SCSI ftp site and I expect will be set up on the accessible directories
some time this week.
The following is the text of the change control list, for your
Changes from Revision 1 to Revision 2 (results of X3T10 meeting, Sept., 1995)
1) Editorial changes
A number of minor editorial changes, including modifying wording to
meet the conventions for required functions of using the word "shall".
2) Section N.n.1.3 of section proposed for SPC.
The text is clarified to indicate that while no task attribute requirements
for the Release action are defined, the Release should not be performed
until after any tasks interlocked by the persistent reservation are completed.
3) Section N.n.1.5 of section proposed for SPC.
Text is added to indicate that the Preempt and Clear action clears
ACA tasks and the ACA condition, but does not clear any AEN initiated
by the target. Note that a PERSISTENT RESERVE OUT with the Preempt and
Clear action requested will pass through an ACA condition for the
preempted initiator, but not for other initiators.
4) Section N.m.2.1 of section proposed for SPC.
The generation counting process is modified to be more useful. It
increments on Register, Preempt, and Preempt and Clear so that any
changes in the relationship among the initiators working with the
particular logical unit is indicated with a new Generation value.
5) Notes for SAM or SAM-2
Notes are provided for inclusion in SAM or SAM-2 to clarify the
special behaviors of ACA and RESERVATION CONFLICT status required
by persistent reservations.
6) Unregister with preempt
Section N.n.1.4 and N.n.1.5 should have an indication that the
preempt unregisters the preempted initiator. This will allow
reconfigurations that remove an initiator known to be bad to guarantee
that the replacement initiator will have to reregister before it can
begin participating in the persistent reserve protocol again. Preemption
may also be required in the case where a link restructures itself and
modifies the address of some initiators. Sections N.n.1.2,3,4, and 5
must be modified to indicate that the actions can only be performed
by an initiator that has registered. I have written this error as a
RESERVATION CONFLICT, although an invalid parameter would also be an
7) Scope of key
Section N.n.1.1 is modified to indicate that the reservation key is
registered with a logical unit.
More information about the T10