(A New) Persistent Reservation Question

Roger Cummings roger.cummings at veritas.com
Fri Oct 27 13:30:00 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* Roger Cummings <roger.cummings at veritas.com>
*
Gerry,

Thanks for the clarification. In that case, I'd put forward the following
replacement for the 6th para of 5.5.3.5 which I'd contend is significantly
clearer (George Penokie helped with this wording in a private thread,
although I must point out that he doesn't think that the clarification is
really warranted):

"If the device server receives a PERSISTENT RESERVE OUT command with a
service action of RESERVE from the Initiator that holds the
existing reservation, and the Type and Scope in this PERSISTENT RESERVE OUT
command are identical to the Type and Scope of the existing reservation,
then the Device Server shall not make any change to the existing reservation
and shall return a GOOD status."


Which leaves me with a clear concern with respect to the situation that I
identified before. I think it makes no sense to reject a reservation from a
registered Initiator when that Initiator already has all of the rights to
the LU that it wants on the basis of an existing Registrants Only
reservation from some other Initiator.

After all, if you look at Table 9, if another registered Initiator issues a
release in the presence of an existing reservation, then the existing
reservation isn't released and a GOOD status is returned. Why then if
another registered Initiator issues a RO reserve in the presence of an
existing RO reservation, isn't the existing reservation retained and GOOD
status returned?

Regards,





Roger

-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
Sent: Friday, October 27, 2000 3:29 PM
To: t10 at t10.org
Subject: Re: (A New) Persistent Reservation Question


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*

Roger asked:

>Is the 6th paragraph of 5.5.3.5 intended to refer ONLY to a second reserve
>that is IDENTICAL in type, scope and source (initiator) to an existing
>reservation ??

My answer: Yes it is.

You are correct that other initiators can inherit access from a registrants
only reservation, but they cannot become the owner of that reservation
unless the original owner (initiator) releases his reservation. This is a
feature, not a bug. The difference is response you have noted is an easy
way to tell whether you are the owner of the reservation or if another
initiator is.





Roger Cummings <roger.cummings at veritas.com>@t10.org on 10/27/2000 10:49:23
AM

Sent by:  owner-t10 at t10.org


To:   "'t10 at t10.org'" <t10 at t10.org>
cc:

Subject:  (A New) Persistent Reservation Question


* From the T10 Reflector (t10 at t10.org), posted by:
* Roger Cummings <roger.cummings at veritas.com>
*
Folks,

I have a question about the definition of Persistent Reservations in SPC-2
that I don't believe is covered by anything currently in 00-267r2. The
question is related  to the following:

The 6th paragraph of 5.5.3.5 (with the response to Quantum #402 included)
says:

"If the device server receives a PERSISTENT RESERVE OUT command with a
service action of RESERVE where
the TYPE and SCOPE are the same as the existing TYPE and SCOPE from the
initiator that created the persistent reservation,
it shall not make any change to the existing reservation and shall return a
GOOD status."

I'm not sure that I can parse this sentence correctly, but at face value it
appears to conflict with Table 9, where any Reserve command  received where
the addressed LU has a reservation from a different initiator gets a
conflict.

Is the 6th paragraph of 5.5.3.5 intended to refer ONLY to a second reserve
that is IDENTICAL in type, scope and source (initiator) to an existing
reservation ??

What I'm worried about is this situation:

1) There's an existing Registrants Only (RO) LU reservation to LU 1 from
registered Initiator A.
2) An identical RO LU reservation to LU 1 is received from Registered
Initiator B.

can the reservation in 2) get a Good (allowed) response, per 5.5.3.5 ???

Note the prior reservation doesn't need to change to grant B access
[because
the reservation in 1) allows Initiator B full access anyway].

To look at this from another way, does it really make sense that the
reservation in 2) above gets a conflict when just about any other command
that Registered Initiator B sends will be allowed ?? Surely it would be
better, in the case where the rights granted under the new reservation
would
be IDENTICAL to the existing reservation, to allow the command and not
change the existing reservation (i.e. make the response allowed in the 3rd
column of table 9 and have a note similar to the one for Release).

Regards,







Roger Cummings
VERITAS Software

roger.cummings at veritas.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