FW: Proposed Clarifications for Persisten Reservation

Tom Coughlan Tom.Coughlan at digital.com
Mon Mar 16 05:10:37 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Tom Coughlan <Tom.Coughlan at digital.com>
*
The four issues described below have been identified during the
implementation of Persistent Reservation.  A change to SPC-2 is proposed
to resolve each issue.  

The following proposal is based on the text contained in SPC-2 Rev. 1. 

Issue #1:  Insufficient Resources

The logical unit may have a limited amount of non-volatile memory in
which to store persistent reservations and reservation keys.  What
should a Logical Unit do when a resource limitation causes it to be
unable to perform a Persistent Reserve Out?  The behavior in this
situation should be consistent, so that Application clients can detect
the situation and take appropriate actions.

I propose the following change at the earliest time allowed by the
standardization process:

Add this paragraph to SPC-2 at the end of Section 7.13 (before Section
7.13.1).  

		"If the device server does not have adequate resources
to perform a PERSISTENT RESERVE OUT command, the device server shall
return CHECK CONDITION status. The sense key shall be set to ILLEGAL
REQUEST and the additional sense data shall be set to INSUFFICIENT
RESOURCES."

INSUFFICIENT RESOURCES is proposed as a new ASC code, because there does
not appear to be an existing code that conveys the same meaning.  (The
two best candidate were SYSTEM BUFFER FULL and PROGRAM MEMORY AREA IS
FULL, but these do not appear to be appropriate when referring to the
target's reservation storage resources.)  The SPC-2 editor is requested
to assign an ASC code for INSUFFICIENT RESOURCES, and add it to tables
67 and B.1.  The INSUFFICIENT RESOURCES code shall apply to the same
command sets as the PERSISTENT RESERVE OUT command.

Issue #2: Duplicate Reservation Descriptors

Should the PERSISTENT RESERVE IN command with a Read Reservations
service action deliver duplicate reservation descriptors to the
application client?

The device sever may contain duplicate reservation descriptors under two
circumstances:

1.	A particular initiator creates the same reservation multiple
times.
2.	Multiple initiators with the same key create identical
compatible reservations.

Note that in the first case the reservation descriptors are identical
because the reservations are identical.  In the second case the
reservations are unique because they are from different initiators, but
since descriptors do not include the initiator identifier, the
descriptors are identical.

Also note that the device server is not required to store duplicate
reservations from the same initiator, because the duplicates serve no
useful function.  In fact, steps were taken in 97-218r2 to facilitate
this option, by stipulating that multiple identical reservations from
the same initiator are all simultaneously released by a single Release
service action. 

Thus, the device server should not be required to send multiple
reservation descriptors for duplicate reservations.  In fact, it is
desirable to prohibit this, so that the application client can
unambiguously detect the second circumstance described above.  The
standard should explicitly state that the Read Reservations service
action shall return one reservation descriptor for each unique
reservation.   A note should be added to indicate that duplicate
reservation descriptors are possible if initiators use the same key. 

The specific proposal is to make the following changes at the earliest
time allowed by the standardization process:

7.12.1.2 Read Reservations
The Read Reservations service action requests that the device server
return a parameter list containing a header and a complete list of all
>>unique<< persistent reservations that are presently active in the
device server and its extents.  >>(Duplicate persistent reservations
|from the same initiator shall not be reported.)<<

7.12.3 PERSISTENT RESERVE IN parameter data for Read Reservations

(Starting in the fourth paragraph.)

The format of a single read Reservation descriptor is defined in table
40. There shall be one read Reservation descriptor for each >>unique<<
persistent reservation held on the logical unit by any initiator.
>>(Duplicate persistent reservations from the same initiator shall not
be reported.)<<

For each >>unique<< persistent reservation held on the logical unit,
there shall be a read Reservation descriptor presented in the list of
parameter data returned by the device server in response to the
PERSISTENT RESERVE IN command with a Read Reservations action. The
descriptor shall contain the Reservation Key under which the persistent
reservation is held. The Type and Scope of the persistent reservation as
present in the PERSISTENT RESERVE OUT command that created the
persistent reservation shall be returned (see 7.12.3.1 and 7.12.3.2).
>>Duplicate Reservation descriptors are possible, if multiple initiators
use the same reservation key.<<

Issue #3:  The Type and Scope fields shall be ignored in the Register
service action 

What should the Type and Scope fields in a PERSISTENT RESERVE OUT
command with a service action of Register be set to?  

SPC-2 should be modified to indicate that these fields are ignored in a
Register service action.  

The proposal is to make the following change at the earliest time
allowed by the standardization process:

7.13 PERSISTENT RESERVE OUT command

(modify the sixth paragraph as shown)

The PERSISTENT RESERVE OUT command contains fields that specify a
persistent reservation Service action, the intended scope of the
persistent reservation, and the restrictions caused by the persistent
reservation. The Type and Scope fields are defined in 7.12.3.1 and
7.12.3.2. >>The Type and Scope fields are ignored for the Register
service action.<<  If a Scope field specifies a scope that is not
implemented, 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 CDB.

Issue #4:  A wording correction in the Register clause 

The word "reservation" was used in Section 7.13.1.1 when the word
"registration" was apparently intended.

The proposal is to make the following change at the earliest time
allowed by the standardization process:

7.13.1.1 Register

The PERSISTENT RESERVE OUT command executing a Register service action
registers a reservation key with a device server without generating a
reservation. For each initiator that performs a PERSISTENT RESERVE OUT
Register service action, the device server shall retain the reservation
key until the key is changed by a new PERSISTENT RESERVE OUT command
with the Register service action from the same initiator or until the
key is reset to the default value of zero or until the initiator
registration is removed by one of the following actions:
		a) powering down the logical unit, if the last APTPL
received by the device server was zero (see 7.13.2);
		b) performing a Clear service action;
		c) performing a Preempt service action; or
		d) performing a Preempt and Clear service action.
When the >>registration<< has been removed, the default reservation key
of zero shall be used when the initiator registers a reservation key
again. When the reservation has been re-moved, no information is
reported for the initiator in the Report Keys service action.
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