Proposal for Additional Persistent Reservation Functions

Ron Gould ron at core.rose.hp.com
Fri Sep 6 00:41:25 PDT 1996


* From the SCSI Reflector (scsi at symbios.com), posted by:
* Ron Gould <ron at core.rose.hp.com>
*
>
>>I'm having a hard time understanding how the Preempt and Clear action
>>would be used against nonregistered initiators.  
>
>The protocol I envisioned would go like this:
>
>Each initiator that is sharing the device registers a reservation key
>and then does a "Shared Access, Registrants Only" Reserve.  When any of
>the initiators/hosts detects that one or more of the other initiators is
>unresponsive it must communicate with the survivors to determine that this
>remnant of the original set of initiators has the right to take ownership
>of the device.  If it does, then:
>
>	- One or all of the survivors issues a Clear to the device.  This 
>	  removes all reservations and registration keys.

This has removed the reservations without stopping the flow of requests
to the device.  The device will create an Unit Attention condition for
all the initiators that had reservations removed, but once the contingent
allegiance condition is cleared (by an auto-sense in FC) any requests
that are issued to the device (may be several queued up in a smart adapter)
will be executed without any restriction of reservations since all were 
cleared.  The reservation access control is not re-established until the
Preempt and Clear is issued.  Although this approach may work it seems to 
be inconsistent, some requests execute with a reservation and some without.

>
>	- All the survivors issue a Register.
>
>	- One or all of the survivors issues a Preempt and Clear, with a 
>	  type code of "Shared Access, Registrants Only" and a Service
>	  Action Reservation key of zero.  This causes all non-registered
>	  initiators to be locked out and to have their task sets aborted.

If you don't want to abort the task set of any surviving initiator then
you don't want to issue this Preempt and Clear until all the survivors
have registered.  This presents a synchronization issue that will require
the hosts to communicate with each other.

If the reservation key of the unresponding initiator is known by one or
more survivor then the best approach would be to have one or more of the
survivors issue a Preempt and Clear on the unresponding initiator's 
reservation key.  This has the advantage of being quick and not impacting 
any of the survivor's requests.

If the reservation key of the unresponding initiator is not known by
any of the survivors then there may be a few ways to stop the accepting
of requests from the unresponding initiator.  There is the method that
you mention above this has some disadvantages.  The main advantage of 
this approach is that tasks from surviving initiators are impacted little,
one command will fail to execute due to the Unit Attention that needs to
be reported.  For disk devices this command can just be retried.  The other
method I was thinking about would be to have a survivor issue a Preempt
and Clear that will preempt all reservations and abort all task sets.
The disadvantage of this approach is that all the tasks of surviving
initiators are impacted.  And until those surviving initiators register
and reserve, all newly issued requests will receive reservation conflicts
(the first one should probably get the Unit Attention.  The surviving
initiators aborted tasks and newly issued request that failed due to 
its reservation being removed will need to be retried after the surviving
initiator registers and reserves.

>
>Although it is not explicit, my reading of the current SPC text is that a
>service action key of zero on a Preempt or Preempt and Clear is always
>illegal.  My proposal would allow it to be zero for Preempt and Clear, and
>it would have the obvious meaning, that is, it would specify those
>initiators whose reservation key is currently zero.
>

I was wanting to use the 0 value to mean all reservation keys.  All
reservation keys behavior could be implemented by the initiator just
get the list of all registration keys and issuing a Preempt and Clear
on each reservation key.


Ron Gould
ron at core.rose.hp.com

*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list