PLEASE EVALUATE proposal for "Persistent Reserve".
Bob.Snively at Eng.Sun.COM
Tue Jan 24 00:19:28 PST 1995
To: scsi at wichitaks.hmpd.com
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
The Persistent Reserve In/Out commands have the following functional
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
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
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
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
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
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