RESERVE(10)/RELEASE(10) - Third Party Reservations

John Tyndall jtyndall at crossroads.com
Wed Oct 3 06:02:54 PDT 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* "John Tyndall" <jtyndall at Crossroads.com>
*
I think Jim is correct except in cases 4b and 4c. I don't believe a
reservation conflict will be issued. I believe that a GOOD status should
be returned, but the reservation will NOT be cleared. This is based on
the language in the RELEASE(10) description (7.16.1 - SPC2r19) that
follows:

"It is not an error for an application client to attempt to release a
reservation that is not currently valid, or is held by another
initiator. In this case, the device server shall return GOOD status
without altering any other reservation."

I believe the thinking here is that it does no harm to let an initiator
think he has released a reservation he never held, since the final state
of the device is the same in either case (i.e. the issuing initiator
does not hold the reservation). At least that is how I have always read
this. Haven't looked at SPC-3.

John Tyndall
Architect
Crossroads Systems Inc.
Email  : jtyndall at crossroads.com
Phone : 512-928-7282


-----Original Message-----
From: Jim Hafner [mailto:hafner at almaden.ibm.com]
Sent: Tuesday, October 02, 2001 5:35 PM
To: Kevin D Butt
Cc: t10 at t10.org
Subject: Re: RESERVE(10)/RELEASE(10) - Third Party Reservations


* From the T10 Reflector (t10 at t10.org), posted by:
* "Jim Hafner" <hafner at almaden.ibm.com>
*

Kevin,

I'll try to answer some of your questions, (with comments in line
<JLH>...</JLH>).

The key to understanding the reservation/release and persistent
reservation
protocols is to understand the difference between the "owner of the
reservation" and the "user of the reservation rights".
The owner is always the one that made the reservation (issued the
RESERVATION command).  It is only this initiator that can (politely
release
the reservation).   The user is the one to whom the rights are granted
(the
owner for first party reservations and the third party in third party
reservations).  The user can't (without a hammer) release a reservation.

I hope that makes it more clear (and I didn't get it wrong).

Jim Hafner


Kevin D Butt/Tucson/IBM at IBMUS@t10.org on 10/02/2001 02:48:48 pm

Sent by:  owner-t10 at t10.org


To:   t10 at t10.org
cc:   t11 at t11.org
Subject:  RESERVE(10)/RELEASE(10) - Third Party Reservations



* From the T10 Reflector (t10 at t10.org), posted by:
* "Kevin D Butt" <kdbutt at us.ibm.com>
*
I need some clarification to the third party reserve functionality
described in the RESERVE(10)/RELEASE(10) commands.  I have copied part
of
their descriptions from SPC-3 and placed it below.

1)  What is the Device ID format for SCSI protocol?
I assume the device id is the Initiators ID from the I.T.L. e.g.
Initiator
ID 07 wishes to reserve Target ID 01 for Initiator ID 06 would send a
0x06
in the THIRD-PARTY DEVICE ID field.
<JLH>
That's my understanding.  See SPI-4 for the description of how this is
placed in "long format" (8byte) version.
</JLH>

2)  What is the Device ID format for Fibre Channel protocol?
Is the THIRD-PARTY DEVICE ID field the three byte fibre address, the
WWID
Node Name, or the WWID Port Name of the Initiator to which the
reservation
is to be transferred?  I would guess that it would be the WWID Port
Name.
<JLH>
Unfortunately, it's not the WWN.  It's the S_ID (1byte on loop and 3byte
on
fabric).  See FCP-2 for how this fits in the format.
</JLH>


3)   The description states that the reservation is in effect until
superseded or released by the same initiator that made the reservation.
Therefore, if Initiator ID 07 made a third party reservation for
Initiator
ID 06 then Initiator ID 06 would not be able to release itself from that
reservation but would have to wait until Initiator ID 07 decided to
supersede or release that reservation for Initiator ID 06.  Is this
correct?
<JLH>
Yes, that's my understanding.  Though Initiator ID 06 could issue a
target
or lu reset and clear the reservation as well.
</JLH>

4)  Following are scenarios which may or may not be allowed.  Please
advise
as to which are legal/illegal and which actually transfer/release
reservations on Target ID 01.

a)  Initiator ID 07 issues RESERVE(10) to Target ID 01 with THIRD-PARTY
DEVICE ID equal to 06.  Initiator 06 performs I/O to Target ID 01 then
issues RESERVE(10) with THIRD-PARTY DEVICE ID equal to 07.
<JLH>
This should cause a reservation conflict on 06's reserve command.
</JLH>

b)  Initiator ID 07 issues RESERVE(10) to Target ID 01 with THIRD-PARTY
DEVICE ID equal to 06.  Initiator 06 performs I/O to Target ID 01 then
issues RELEASE(10) to Target ID 01 with 3RDPTY bit 0.
<JLH>
Also should cause a reservation conflict.
</JLH>

c)  Initiator ID 07 issues RESERVE(10) to Target ID 01 with THIRD-PARTY
DEVICE ID equal to 06.  Initiator 06 performs I/O to Target ID 01 then
issues RELEASE(10) with THIRD-PARTY DEVICE ID equal to 06.
<JLH>
Also should cause a reservation conflict.
</JLH>

d)  Initiator ID 07 issues RESERVE(10) to Target ID 01 with THIRD-PARTY
DEVICE ID equal to 06.  Initiator 06 performs I/O to Target ID 01 then
signals to Initiator ID 07 in methods outside the SCSI protocol that
it's
done.  Initiator ID 07 then issues RESERVE(10) to Target ID 01 with
THIRD-PARTY DEVICE ID equal to 07.  It then issues a RELEASE(10) to
Target
ID 01 with THIRD-PARTY DEVICE ID equal to 07.
<JLH>
I'm not sure about this one.  A careful reading is required (and I'm
going
to skip that for now).  Based on what you quoted below, I think this is
OK.
</JLH>

e)  Initiator ID 07 issues RESERVE(10) to Target ID 01 with THIRD-PARTY
DEVICE ID equal to 06.  Initiator 06 performs I/O to Target ID 01 then
signals to Initiator ID 07 in methods outside the SCSI protocol that
it's
done.  Initiator ID 07 then issues RESERVE(10) to Target ID 01 with
3RDPTY
bit 0.  The drive is now reserved to Initiator ID 07.
<JLH>
This is the correct handling.
</JLH>

>From the RESERVE(10) description in SPC-3 (and SPC-2):

If the 3RDPTY bit is one then the device server shall reserve the
specified
logical
unit for the SCSI device specified in the THIRD-PARTY DEVICE ID field.
Device ID formats are protocol specific.

The device server shall preserve the reservation until it is superseded
by
another valid RESERVE command from the
initiator that made the reservation or until it is released by the same
initiator, by a TARGET RESET task
management function performed by any initiator, a hard reset condition,
or
by a power on cycle. The device server
shall ignore any attempt to release the reservation made by any other
initiator.

After a third-party reservation has been granted, the initiator that
sent
the RESERVE command shall be treated like
any other initiator. Reservation conflicts shall occur in all cases
where
another initiator is not allowed access due to
the reservation.

7.21.4 Superseding reservations
Superseding reservations is mandatory if the RELEASE(10) command is
implemented. An application client that
holds a current logical unit reservation may modify that reservation by
issuing another RESERVE command to the
same logical unit. The superseding RESERVE command shall release the
previous reservation state when the
new reservation request is granted. The current reservation shall not be
modified if the superseding reservation
request cannot be granted. If the superseding reservation cannot be
granted
because of conflicts with a previous
reservation, other than the reservation being superseded, then the
device
server shall return RESERVATION
CONFLICT status.

NOTE 35 - Superseding reservations allow the SCSI device ID in a
third-party reservation to be changed. This
capability is necessary for certain situations when using the EXTENDED
COPY
command.

>From the RELEASE(10) description in SPC-3 (and SPC-2):

A reservation may only be released by a RELEASE command from the
initiator
that made it.

If the 3RDPTY bit is one then the device server
shall release the specified logical unit, but only if the initiator ID,
3RDPTY bit,
and THIRD-PARTY DEVICE ID are identical when compared to the RESERVE
command that established the reservation.


Kevin D. Butt
IBM Tape Products
SCSI and Fibre Channel Microcode Development
65U/9032-2, 9000 S. Rita Rd.
Tucson, AZ  85744
Phone:  (520)799-5280, Tie-line 321-5280
Fax:  (520)799-4062
Email:  kdbutt at us.ibm.com

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



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




More information about the T10 mailing list