Persistent reservation issue

Gerry_Houlder at Gerry_Houlder at
Tue Aug 18 13:10:06 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* Gerry_Houlder at
George, your 3 choices seem to imply a model where persistent reservations
apply to targets instead of logical units. I vote for option 4: persistent
reservations apply only to the addressed logical unit and therefore there
is no need to generate unit attentions when an initiator unregisters or
changes its key with one LUN.

The previous RESERVE/ RELEASE commands were "Logical Unit Reservations".
The PERSISTENT RESERVE IN command is addressed to a device server of an
individual LUN, so there is no implication that a registered key (or a
persistent reservation associated with that key) applies to anything but
that particular LUN. In my view, an initiator must register and reserve
with each LUN separately, just like mode pages must be set up individually
for each LUN (OK, except for mode page 0x19, which may only be supported by
LUN 0 per the last working group meeting ..).

Have you written something into the new persistent reservation description
that make it apply to a target and not just a LUN? If so, I really missed
it. If so, I think it should be changed back to a LUN reservation. This is
so much easier to handle in the model.

>Another question has come up about initiators and keys in a multiple
>unit environment In the case where an initiator is registered to multiple
>logical units within a single target what happens if the initiator changes
>key for one of the logical units? Right now we have a rule that states an
>initiator can only use one key.
>We have come up with three solutions but the committee needs to decide
>solution will go into the standard:
>1-Any change to one key changes all the keys to the new value for any
>logical units under that initiator then issue an unit attention for those
>logical units. In this case an unregister of one would also cause all the
>logical units under the unregistering initiator to be unregistered.
>2-Before changing an initiator/key the initiator must deregister all but
one >of
>the keys before it can change a key (i.e., an initiator is only allowed to
>change a key if it is registered to only one logical unit). Any attempt to
>violate this rule would cause an error.
>3-Accept the reregister and unregister all other logical units under the
>key/initiator pairs. Note that once the logical unit is unregistered it is
>pointless  to set an unit attention because no commands can get to the

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list