Questions on Persistent Reserve

Bob Snively Bob.Snively at Eng.Sun.COM
Mon Jul 8 22:07:02 PDT 1996

* From the SCSI Reflector, posted by:
* Bob.Snively at Eng.Sun.COM (Bob Snively)

>From monia at Mon Jul  1 12:48:12 1996
>Subject: Questions on Persistent Reserve
>I have the following questions on Persistent Reserve (as described in
>a) On what basis is a reservation type deemed nonconflicting? The first
>paragraph on pp 14 says persistent reservations may be generated "as
>long as the reservations are not contrary to existing reservations". The
>meaning of "not contrary" is not self-evident.  For instance, does
>exclusive read, shared write conflict with shared read, shared write? 
>Maybe it would be clearer if the nonconflicting types were enumerated in
>a seperate table.


SPC Rev 9b, dated 10 May, does a rather nice job of enumerating those
functions.  If it is still unclear after reviewing that, please let me
and Ralph know.  Exclusive read with shared write will conflict with
shared read of any type, and I think that Ralph's enumeration in table 41 
clarifies that case nicely.

>b) What are the interactions with initiators that have no reservations
>in effect?  For example, does a read shared, write shared reservation
>prohibit a non-reserving initiator from accessing the device?

Shared read/shared write allows any initiator to do a read or write,
but allows no other initiator to do a reservation.

>c) Why is a code 4 reservation ( read shared, write shared) designated
>as "non-conflicting, this initiator"?  Why should another initiator be
>prohibited from making the same type of reservation?

This is a "do what you will, but don't mess with my reservation" command.

>Reservation Behavior
>In FCP and parallel SCSI, reservations are checked using the link
>address (FCP port address or SPI bus address). If the address changes, 
>the old reservation remains in force and it's the initiator's job to
>clean up.  In that case, I assume that a preempt or preempt and clear
>using the same key value for the port and preempted port will have the
>desired effect of remapping the key to the new link address.  Is that

Assuming the preemption was executed correctly, that should do nicely.

Hope that is some help,



Bob Snively				         Phone:	   (415) 786-6694
Sun Microsystems Computer Company	         FAX:	   (415) 568-9603
Mail Stop UMPK 12-204
2550 Garcia Avenue			   	 E-mail:   bob.snively at
Mountain View, CA 94043-1100

>* Charles Monia Storage Architecture Group                         *
>* Digital Equipment, Shrewsbury MA   Internet: monia at   *
>* Tel: (508) 841-6757    X400: c=US; a=MCI; o=Digital; ou=SHR      *
>* Fax: (508) 841-6100                                              *

More information about the T10 mailing list