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
reference.

				Change control

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 
acceptable error. 

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 mailing list