Review of the impact of persistent reservations on non-media acce ss commands.

Tom Coughlan Tom.Coughlan at digital.com
Fri Mar 13 06:31:19 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Tom Coughlan <Tom.Coughlan at digital.com>
*
Questions regarding the interaction between persistent reservations and
commands that do not explicitly read or write the medium have arisen
during the implementation of persistent reservation.  (For simplicity,
I'll refer to these commands as non-media access commands in the
following.)  For example, if one initiator is holding a persistent
reservation with type Read Exclusive and scope Logical Unit, does
another initiator receive a reservation conflict in response to a Test
Unit Ready command?  The answer is not obvious, because the logical unit
is "ready" for writes, but not "ready" for reads.

The standard is fairly clear on the answer to this, though the answer is
probably not what most applications would like to see.  I believe that
this issue is on the WG agenda for San Diego (6.14 Persistent
Reservation Questions (reflector messages) [Houlder]).  I hope that the
following background and analysis of possible alternatives will help to
frame the debate.

The SPC-2 Rev.1, Section 5.3, entitled "Reservations", states:

		"Commands that do not explicitly read or write the
medium may conflict with the restrictions established by a previous
reservation. ... The particular reservation restrictions imposed are
highly dependent on the relationship between the command and the type of
reservations. The restrictions do not depend on the reservation
management method and may not be the same as the restrictions for
commands that explicitly read or write the medium."

The phrase "the restrictions do not depend on the reservation management
method" indicates that the restrictions on a command are the same for a
traditional reservation as they are for a persistent reservation.  This
is a simple rule that minimizes the amount of change to the standard.
The downside is that this rule makes it difficult to use one of the new
capabilities provided by persistent reservations: shared access to
logical units.

The traditional reservation management method does not provide shared
access to logical units.  Rather, it provides two modes of operation:

1.	Exclusive access to the Logical Unit.  This type of reservation
blocks all other initiators from executing all commands, except for the
most basic commands necessary to detect the existence of the device (for
example, Inquiry, Request Sense, Report LUNS).  
2.	Shared or exclusive access to extents.  This type of reservation
unconditionally allows a broader set of non-media access commands (like
Test Unit Ready and Mode Sense), and conditionally allows others (like
Mode Select and Send Diagnostic), depending on whether the command
conflicts with the specific reservations that are present.  Other
commands (like Start Stop Unit) are always blocked by another
initiator's reservation.

The persistent reservation method provides shared access to logical
units.  The question is, can this capability be used if all non-media
access commands except Inquiry, Request Sense and Report LUNS fail on
initiators that do not hold the reservation?  The precedent set by
traditional reservation suggests not.

I see the following three alternatives:

Alternative #1 

Live with it, but make the standard more explicit, so that we have a
better chance that everyone will implement non-media access commands the
same way.  

This severely limits the usefulness of most of the shared reservation
types with logical unit scope.  How does a host deal with a device that
it can read and/or write but can not do a Test Unit Ready or Mode Sense
to?  It is not practical to expect host-to-host communication to provide
coordination at such a low level of the device driver.  

(It should be noted that some of the shared reservation types can be
held simultaneously by all interested initiators.  Those reservation
types are not impacted as severely by this issue.) 

An application can avoid the problem by using extent reservations when
shared access is desired, but extent reservations bring along additional
implementation complexity that most implementers are hoping to avoid. 

Alternative #2

Change the standard to state that the reservation behavior of non-media
access commands when a shared access logical unit reservation exists is
the same as when an extent reservation exits.  This would require going
through the command standards and updating them to specify the behavior
for the shared access logical unit reservations.  An example of how this
might be done is as follows:

Add text to SPC-2, section 5.3, that says, in effect:  

		"There are two types of Logical Unit reservation, 1)
exclusive access (traditional Reserve, and Persistent Reservation with
type Exclusive access) and 2) shared access (all the other Persistent
reservation types)."

Then, for example, modify the current text for the Mode Select command,
which says:

		"If reservations are active, they shall affect the
execution of the MODE SELECT command as follows. A reservation conflict
shall occur when a MODE SELECT command is received from an initiator
other than the one holding a logical unit reservation. If an initiator
has an extent or element reservation on an SCSI device, and an another
initiator sends a MODE SELECT, a reservation conflict shall occur if the
MODE SELECT affects the manner in which access to an extent or element
reserved by the first initiator is performed. If the MODE SELECT does
not affect access to any reserved extent or element, or mode parameters
are saved for each initiator, then a reservation conflict shall not
occur."

to say:

		"If reservations are active, they shall affect the
execution of the MODE SELECT command as follows. A reservation conflict
shall occur when a MODE SELECT command is received from an initiator
other than the one holding an exclusive logical unit reservation. If an
initiator has a shared access logical unit reservation or an extent or
element reservation on an SCSI device, and an another initiator sends a
MODE SELECT, a reservation conflict shall occur if the MODE SELECT
affects the manner in which access to an extent or element reserved by
the first initiator is performed. If the MODE SELECT does not affect
access to any reserved extent or element, or mode parameters are saved
for each initiator, then a reservation conflict shall not occur."

This alternative has the advantage of being consistent with the
traditional reservation method.  The disadvantage is that there is a lot
of implementation complexity.

Alternative #3

Change the standard to state that non-media access commands are never
blocked by shared reservations with logical unit scope.  

This is not as crazy as it sounds.  The Persistent Reservation In
command provides each initiator with the ability to examine the
reservation state of the logical unit.  If we make the reasonable
assumption that a shared-access logical unit reservation implies a
strong degree of multi-initiator cooperation, then we can count on
initiators to act graciously with regard to their non-media access
commands. This puts the responsibility on the application to examine the
reservation state, and if necessary, to coordinate with the other
initiators that are sharing the logical unit, and refrain from doing bad
things.  This also gives the application the freedom to decide what is
bad and good, based on its particular requirements.  This is more
appropriate than having the Standard try to guess what the right
reservation behavior is for all applications. 

It will be noted that this further erodes the usefulness of reservations
as a way for one or more initiators to protect storage from unauthorized
access by non-cooperating initiators.  I do not see this as a
significant disadvantage, since reservations are not intended to provide
this level of security, nor can they be used reliably for this purpose
today.

Alternative #3 looks the most promising to me.  I am interested hear
what other people have to say.

Tom Coughlan
OpenVMS SCSI Project Leader
Digital Equipment Corporation
110 Spit Brook Rd. ZKO3-4/U14
Nashua, New Hampshire 03062-2698
Telephone:  603-884-0933 
Fax.:  603-884-0189
Mail:  tom.coughlan at digital.com

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





More information about the T10 mailing list