PLEASE EVALUATE proposal for "Persistent Reserve".

Bob Snively Bob.Snively at Eng.Sun.COM
Tue Jan 24 00:19:28 PST 1995

To:		scsi at

From:		Bob Snively

Date:		Jan 10, 1995

Subject:	PLEASE EVALUATE proposal for "Persistent Reserve".

Bill Dallas of DEC has suggested a slightly different
approach to the multi-port multi-initiator problem.
The disadvantage of his proposal is that it requires more
significant changes to the present drivers and SCSI
documents.  The advantage of his proposal is that it
provides a fairly good mechanism for using the SCSI
peripheral device to assist in the communication
among initiators and allows parallel SCSI implementations
to use the full capability.  The
software gurus of the CAM committee seem to feel that
the Persistent Reserve function is desirable.

Bill defines a new function called "Persistent Reserve".
It has all the properties of a normal reserve except that
it is not cleared by Target or LUN Reset (Bus Device Reset) or by 
SCSI RST for those protocols that have that capability.  
It is only cleared by a power cycle or by
a properly qualified Persistent Reserve from another 
Initiator.  It requires the definition of two new commands
having different properties than the present RESERVE/RELEASE
commands.  The commands are Persistent Reserve In and Persistent
Reserve Out.

The Persistent Reserve In/Out commands have the following functional

	For Reservations:



	For ID Presentation:

		Defines a 16-byte current ID for the
		sourcing initiator to the attached device.

	For determination of present/last reservation:

		Recovers the 16-byte current ID for the presently
		reserving initiator.

		Recovers the 16-byte ID for the immediately
		previous reserving initiator.

		This uses the Persistent Reserve In command.

	For over-ride of a present reservation:

		Replaces the current reservation with a Persistent
		Reservation for the issuing initiator IF the
		16-byte current ID provided matches the ID
		of the currently reserving initiator.

		Creates a Persistent Reservation IF there is
		no prresent reservation.

		Provides a Check Condition if the current
		reservation is for an initiator other than
		that specified by the 16-byte ID provided by
		the command.

This command has no effect on reservations established by the
normal RESERVE/RELEASE command and will receive a Reservation
Conflict indication if it is executed to a LUN having a normal
reservation in effect.  Multi-initiator environments must use
ONLY the new reservation command to operate correctly, since there
would be no Priority Reserve command to take over from the old
RESERVE commands.

The ABORT TASK SET, OTHER INITIATOR task management function
works very much like we have defined, except that it uses the
ID defined by the Persistent Reserve command to specify the
initiator for which the ABORT TASK SET will be performed.

Discussion with Roger Cummings and Bill Dallas on 
Persistent Reservation provided these additional recommendations
and clarifications:

a)  IPI allowed a target reservation, LUN reservation,
    and third-party reservation that was persistent until
    explicitly cleared or until Priority Reservation
    was performed.  Once established, a Priority Reservation
    had all the properties of a normal reservation, including
    the capability of being broken by a Priority Reservation.

    IPI also had a physical level reservation too, but
    Roger thought this was not an essential part of the

b)  Bill was studying take over functions.  If a system
    goes down that has a reservation, a Bus Reset or
    Target Reset was required and screwed up everything.

    Bill feels it is useful to have a mechanism for
    identifying the system that has the reservation.
    Rogue systems may not have knowledge of the meaning
    of the identifier and may violate the convention.

c)  Roger feels that the IPI was deficient because the
    physical layer did not provide a response to
    a reservation, so that the reserved state looked
    like a dead device.

d)  Roger feels that the protection of peripherals from
    unauthorized hosts should be done by the switch.

e)  There was some discussion about what happens when
    there are queued tasks in place.  At present, SCSI
    treats reservation as an Ordered Queue operation.
    Bill wants to over-ride them, since queueing may be
    against an initiator that will not serve the queue.
    Roger says that they blasted off all tasks if 
    a reservation could not be made because other tasks
    were present.

    The id will be 8 bytes.

    Bill suggests a bit to indicate whether 
    the reservation will take place as an Ordered or
    Head of Queue command.

    Roger suggests that Lansing Sloane be consulted for
    corner case considerations.

f)  All the task management functions violate reservations.

g)  Abort Task Set Other Initiator is a critical function.

h)  Persistent Reserve does not need a priority reserve,
    since it has a Get PR Info.  The Get PR Info may be
    a list of extent reservations.

More information about the T10 mailing list