Proposal for Additional Persistent Reservation Functions

Tom coughlan at star.enet.dec.com
Wed Sep 4 10:42:22 PDT 1996


* From the SCSI Reflector (scsi at symbios.com), posted by:
* Tom <coughlan at star.ENET.dec.com>
*
I have attached a proposal for two new persistent reservation features. 
These are needed for multi-initiator systems where more than one initiator
has access to a storage device at a time.

I would appreciate your feedback to the SCSI reflector.   I have also asked 
for some time at the SCSI working group next week to discuss this.

Thanks.

Tom Coughlan
SCSI Project Leader, OpenVMS 
Digital Equipment Corporation
Nashua, NH
603-881-0933


Summary:
=======

The current Persistent Reservation commands provide the ability for
one initiator to clear the tasks and reservations of another
initiator, and to prohibit subsequent access by that initiator.  This
capability allows multiple-initiator systems to recover when one of
the initiators becomes unresponsive, due to a failure.  

The current commands work well in multiple-initiator systems where
one initiator coordinates access to a resource, using exclusive access
reservations.  A similar capability is needed for systems that
coordinate access on a more dynamic basis.  In these systems exclusive
access reservations are not used because the overhead associated with
reservation and release is typically  large compared to the length of
time any one initiator "owns" the resource.

This proposal adds one new Persistent Reservation type, and changes
the interpretation of one field in the Preempt and Clear service
action parameter list.  

The new reservation type allows shared access for registered
initiators, and blocks access by unregistered initiators.  The
extension to Preempt and Clear allows the action to be applied to all 
unregistered initiators.  Using these mechanisms, an unresponsive
initiator can be prevented from accessing a shared resource, without
requiring that one surviving initiator take an exclusive access
reservation.  These changes will allow multiple-initiator systems that
implement simultaneous fully-shared access to recover effectively from
the failure of an initiator.

One example of a problem that this proposal addresses has been
referred to in the Serial Concerns forum as the "flailing adapter
problem".  The problem is that an intelligent adapter with a large
queue of work may continue to interact with the device server for a
substantial period of time after its host has halted.  A Preempt and
Clear with exclusive access could be used to block these activities,
so that one initiator could safely take over for the halted system. 
There is no similar capability, however, that would allow multiple
surviving initiators to take over the role of the failed initiator.  

Background:
==========

Multiple-initiator SCSI systems typically require the ability for one
or more initiators to take over the activity of an initiator that
becomes unresponsive due to a failure.  Before this can be done, it is
generally necessary for the survivors to determine that:

	o there are no tasks from the unresponsive initiator in any
	  shared device servers 
	o there are no reservations for the unresponsive initiator 
	  in any shared device servers 
	o no further tasks from the non-responsive initiator will be 
	  accepted by the shared device servers, until the initiator 
	  becomes responsive again.

Note that in most applications it is desirable for these
determinations to be made quickly, since high-availability is one of
the purposes of multiple-initiator systems.  Also, for fast recovery
and system stability, it is desirable for the survivors' tasks to be
unaffected by the removal of the unresponsive initiator.

The Persistent Reservation commands provide tools to accomplish these
goals for some multiple-initiator systems.  In these systems, one of
the survivors may issue a Preempt and Clear service action, to remove
the unresponsive initiators' reservations and tasks, and the new
exclusive reservation can be used to block subsequent tasks that may
arrive from the unresponsive initiator.

This works well in those multiple-initiator systems where reservations
are used to coordinate access to shared device servers.  There are
some multiple-initiator systems, however, where access coordination is
done more dynamically, and the overhead associated with doing a
reservation for each access is not justified.  In these systems, all
of the participating initiators have continuous shared access to the
storage, and they coordinate among themselves to avoid conflicts. 
This type of system does not use any form of exclusive access
reservation in the SCSI device.

Note that the Shared Access reservation type, currently defined for
Persistent Reservation, can be used to achieve the first two of the
three objectives listed above, but not the third.  That is, a Preempt
and Clear service action with Shared Access type clears the tasks and
reservations of the unresponsive initiator, but it does not block
subsequent tasks from that initiator.

Overview of the Change
======================

This proposal adds a new reservation type and a new interpretation for
one of the fields in the Preempt and Clear service action parameter
list.  These changes provide a way to conditionalize the behavior of
the device server based on the set of registered initiators.

The new reservation type is a slight variation of the Shared Access
type.  It allows Reads, Writes, and Reservations, but only for
registered initiators.  This provides systems with the ability to
exclude initiators who are clearly not participating in the sharing
protocol.  As such, this capability is likely to have very general
utility.  This reservation type could be called "Shared Access,
Registrants Only".

The other change is to provide a mechanism that allows an initiator to
perform a Preempt and Clear action on all non-registered initiators. 
This provides a very efficient way for the surviving initiators to
clear the tasks of an arbitrarily large group of unresponsive
initiators, and block their subsequent accesses, until they
re-register.

The new behavior of Preempt and Clear can be specified easily by the
use of a zero in the Service Action Reservation Key field in the
parameter list.  This indicates that the service action applies to
initiators whose Registration Key is zero, that is, those who are not
registered.

(Some of) The Detailed Changes
==============================

(This proposal is bound to change, so I won't try to fill in this section
entirely.  What is here is just to provide a bit more detail on exactly
what is being proposed.)

All of the changes pertain to SPC, in the Persistent Reserve In and
Persistent Reserve Out Sections.  The following references SPC Rev. 9d,
10 May 1996.

Add the following to Table 41 - Persistent Reservation Type Codes.

Code: 5h

Name: Shared Access, Registrants Only

Description:

Reads Shared Among Registered Initiators:  Any command that
performs a transfer from the storage medium or cache of the logical
unit to the initiator, and is from an initiator that does not
have a valid current registration with the device server, shall result
in a reservation conflict.

Writes Shared Among Registered Initiators:  Any command that
performs a transfer to the storage medium or cache of the logical unit
|from the initiator, and, is from an initiator that does not have a
valid current registration with the device server, shall result in a
reservation conflict.

Additional Reservations Allowed:  Any initiator may reserve the
logical unit or extents or elements as long as the persistent
reservations do not conflict with any reservations that are already

Change Section 7.13.2 Persistent Reserve Out Parameter List

In the paragraph describing the Service Action Reservation key field, add
"For the Preempt and Clear service action, a value of zero shall cause the
action to be performed for each initiator that does not have a valid
reservation.  If the value is zero for any other service action, the device
server shall return a CHECK CONDITION status.  The sense key shall be set
to ILLEGAL REQUEST and additional sense data shall be set to INVALID FIELD
IN PARAMETER LIST." 
*
* 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