Proposed Changes to Persistent Reservation

Tom Coughlan Tom.Coughlan at
Thu Apr 29 19:17:51 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* Tom Coughlan <Tom.Coughlan at>

Regarding Change II (that is, "the reservation established by Preempt and
Abort must apply to tasks that arrive after the abort"):

We will probably have better luck working this out in person.  It would help
to know, though, if you agree or disagree with the following statement:  

The Preempt and Abort action is useless if, after the initiator receives
good status, there are any commands from the preempted initiators in the
task set that will not be subjected to the new persistent reservation.  

If you agree with this, then I am confident we can find a way to express the
proper behavior in the standard.

Regarding Change I (that is, "allow the Device Server to ignore the existing
key for Register service actions")

I understand your argument.  We have come to realize, however, that there
are many situations where:
1) there is no one to ask what key the initiator last registered with (or at
least, no one you know how to talk to)
2) the cluster protocol has been designed to allow an initiator to safely
register without incurring the overhead of learning the old key value.  

In these situation the default initialization behavior will be to
unconditionally "do the dance". Assuming that this sort of implementation is
widespread, then the dance provides no security. At the very least, the
advantage of being able to reliably register with a single SCSI command
outweighs whatever small amount of "security" remains.   


-----Original Message-----
From: Bob Snively [mailto:Bob.Snively at Ebay.Sun.COM]
Sent: Thursday, April 29, 1999 1:31 PM
To: t10 at Symbios.COM; Tom Coughlan
Subject: Re: Proposed Changes to Persistent Reservation


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
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
favor of the status quo is flawless:

	"The argument in favor of the status quo is presumably based on a
	to protect the logical unit from an initiator that is not
	in the proper key assignment algorithm."
This is exactly the type of security that is intended by Persistent
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