Bob's comments on persistent reservation

Bob Snively Bob.Snively at Eng.Sun.COM
Thu Jul 10 17:03:56 PDT 1997


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Bob Snively <Bob.Snively at Eng.Sun.COM>
*
George,

I have cross-checked your proposals with mine and the spec and come to the
conclusion that I still like mine better.  My reasoning is interspersed
below.

Bob


> 
> I have a different interpetation for the the statement from SPC you have
> a problem with:
> "(with a Reserve service action that does not conflict with established
> persistent reservations or tasks)"
> 
> I aggree it is worded poorly but I think changing the wording as follows
> would clear it up and capture the actual intent:
> "(with a Reserve service action that does not conflict with established
> persistent reservations or tasks relating to established persistent
> resetvations)"

What defines a task relating to an established persistent reservation?
I would submit that any task that needs to be checked against a
reservation (read, write, lots of control tasks) are actually "relating to"
an established persistent reservation.  I think I undestand where 
you are going if we said instead:

"(with a Reserve service action that does not conflict with established
persistent reservations or with any PERSISTENT RESERVE OUT tasks)"

However, you cannot tell about conflicts with other tasks until the
the particular PERSISTENT RESERVE OUT command is started and the previous
PERSISTENT RESERVE OUT commands are >> FULLY << completed.  So I still
think my wording is better:

"(with a Reserve service action that does not conflict with established 
persistent reservations)"


> 
> I also have problems with the changes to the notes. Adding the first
> sentence to the existing wording is OK. But the remaining sentences
> force all persistent reservation out commands to be ordered (your
> wording seems to have come right out of the queuing model definition of
> ordered queue tags) reguardless of the actual tag (if any) that is
> received with the command. I do not think it is a good idea to create
> commands that override the queue tags. 

Lets review my wording and intent:

	NOTE xx: The time of effectiveness of a reservation with respect
	to other tasks being managed by the device server is vendor 
	specific.  Successful completion of the PERSISTENT RESERVE OUT 
	command indicates that the new reservation is active.  An active
	reservation may apply to some or all tasks queued before the
	completion of the PERSISTENT RESERVE OUT command.  The reservation
	shall apply to all tasks received after completion of the 
	PERSISTENT RESERVE OUT command.
	
Note that the time of checking for a reservation conflict is not specified
anywhere.  The only condition is that stored data or machine state not  
be modified if there is a reservation conflict and that read data not be 
delivered if there is a reservation conflict.  I would expect that you
could check the reservation at the time the command is queued or that the
reservation could be checked at the time the command execution is actually
started without violating SAM.  Many would prefer the former because of
the rapid return of the reservation conflict information.  

Note that there is also no specification about when a reservation is 
actually established except that it is not present before sending the 
command and is present after successful command status is returned.  

Given these two pieces of perhaps arguable information, my wording of the
note is intended to clearly indicate that, if you perform reservations in
the course of on-going operations, the results will not be perfectly
predictable except for commands transmitted after the successful completion
of the reservation. 

As you know, this is only one of many reasons that I mistrust the
ordered queueing attribute.





*
* 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