Proposed Changes to Persistent Reservation

Bob Snively Bob.Snively at Ebay.Sun.COM
Thu Apr 29 10:31:11 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* Bob Snively <Bob.Snively at Ebay.Sun.COM>

I have reviewed your document 99-182r0 and would like to suggest the
following comments and interpretations.

Starting with the simplest, item III, I believe that the change you are
proposing is mostly harmless and, even though the present text is correct,
may improve the interpretability of the document.

Approaching the intermediate challenge, item II, I believe the change you
are proposing is impossible to implement.  The time at which an atomic action
is taken between the receipt of a command requesting that action and the
transmission of status indicating the successful completion of that action
is impossible to determine.  As a result, commands sliding in during that
period may fall before or after the atomic action takes place and the
results are necessarily indeterminate.  For this reason, the document
explicitly requires an indication of GOOD status before you can trust the
newly established state.  I believe the original cautionary text is correct 
and the change should not be made.

Approaching the most significant question, item I, I believe your argument in 
favor of the status quo is flawless:

	"The argument in favor of the status quo is presumably based on a desire 
	to protect the logical unit from an initiator that is not participating 
	in the proper key assignment algorithm."
This is exactly the type of security that is intended by Persistent Reservation.
If you don't have the magic key, you are forced to perform a special dance,
involving either questioning the other hosts that share your device about
their activities and how they may relate to those you would like to perform,
or alternatively destroying all their activities through an appropriate
series of self-preemptions followed by subsequent preemptions.  This dance
is intended to assure that only consciously malicious hosts can participate
in the persistent reservation protocol without establishing appropriate
agreements about the environment.  I believe that this was the intent and
the actual effect of the present description and I would prefer that it
not be changed.

Thanks very much for your attention,

Bob Snively

Bob Snively			     Phone:	  (510) 574-9051
Sun Microsystems Computer Company      
Mail Stop NWK 04-104
901 San Antonio Road	             E-mail: bob.snively at
Palo Alto, CA 94303

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

More information about the T10 mailing list