REPLACE LOST RESERVATION fixes uploaded ... again ... maybe for the last time

[Kevin D Butt]

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1207252_f.htm">HTML-formatted message</a>

Ralph and George,
Upon further review, I think the problem is this text:
<<The failure detected by the device server may be:
a) recoverable through the combined actions of the device server and 
application client (e.g., sufficient nonvolatile memory is available to 
recreate the lost persistent reservation and registrations information) 
using the processes described in this subclause (i.e., a recoverable lost 
persistent reservation); or
b) unrecoverable, except by operator intervention.
If the device server detects a recoverable lost persistent reservation, 
the device server shall establish a recoverable lost persistent 
reservation condition that the device server shall clear only in response 
to:>>
Item a) is the definition of "recoverable lost persistent reservation" 
while item b) is the definition of an "unrecoverable lost persistent 
reservation".
The "If" clause states that for a recoverable lost persistent reservation 
"the device server shall establish a recoverable lost persistent 
reservation condition" and then further tries to levy a second shall 
requirement about restrictions on the clearing of this new "recoverable 
lost persistent reservation condition" thing.  This leaves one hanging to 
figure out what the "lost persistent reservation condition" thing is.
I wonder if it might be more clear to reword things to clarify the 
different definitions and requirements.  Perhaps something like the 
following:
The failure detected by the device server may be:
a) recoverable through the combined actions of the device server and 
application client (e.g., sufficient nonvolatile memory is available to 
recreate the lost persistent reservation and registrations information) 
using the processes described in this subclause (i.e., a recoverable lost 
persistent reservation); or
b) unrecoverable, except by operator intervention (i.e., an unrecoverable 
lost persistent reservation).
If the device server detects a recoverable lost persistent reservation, 
then the device server shall establish a recoverable lost persistent 
reservation condition. A recoverable lost persistent reservation condition 
is a condition in which the device server shall:
a) not terminate a PERSISTENT RESERVE OUT command with the REPLACE LOST 
RESERVATION service action with RESERVATION CONFLICT status; and
b) terminate with CHECK CONDITION status with the sense key set to DATA 
PROTECT and the additional sense code set to PERSISTENT RESERVATION 
INFORMATION LOST all commands other than:
	A) a PERSISTENT RESERVE OUT command with a REPLACE LOST 
RESERVATION service action;
	and
	B) those commands listed in 5.13.5.2.
 that the The device server shall clear a recoverable lost persistent 
reservation condition only in response to:
a) the successful processing of a PERSISTENT RESERVE OUT command with the 
REPLACE LOST RESERVATION service action (see 5.13.11.3); or
b) prior to the successful processing of a PERSISTENT RESERVE OUT command 
with the REPLACE LOST RESERVATION service action, if the recoverable lost 
persistent reservation becomes an unrecoverable lost persistent 
reservation.
The device server shall not clear a recoverable lost persistent 
reservation condition for other reasons.
<<The strikethrough green - starting at "the device server shall" is moved 
up to the green above.>>
While the recoverable lost persistent reservation condition is in effect, 
the device server shall:
a) not terminate a PERSISTENT RESERVE OUT command with the REPLACE LOST 
RESERVATION service action with RESERVATION CONFLICT status; and
b) terminate with CHECK CONDITION status with the sense key set to DATA 
PROTECT and the additional sense code set to PERSISTENT RESERVATION 
INFORMATION LOST all commands other than:
A) a PERSISTENT RESERVE OUT command with a REPLACE LOST RESERVATION 
service action;
and
B) those commands listed in 5.13.5.2.
If the device server detects an unrecoverable lost persistent reservation, 
then the device server:
a) should operate as if it has non volatile memory that is not ready (see 
5.13.5.2); or
b) may terminate commands other than those commands listed in 5.13.5.2 
with CHECK CONDITION status with the sense key set to HARDWARE ERROR with 
the additional sense code set to an appropriate value.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:	"Penokie, George" <George.Penokie at lsi.com>
To:	Ralph Weber <roweber at ieee.org>, 
Cc:	"'t10 at t10.org'" <t10 at t10.org>
Date:	07/25/2012 06:58 AM
Subject:	RE: REPLACE LOST RESERVATION fixes uploaded ... again ... 
maybe for the last time
Sent by:	owner-t10 at t10.org
* From the T10 Reflector (t10 at t10.org), posted by:
* "Penokie, George" <George.Penokie at lsi.com>
*
Ralph,
Your suggestion to make it an ordered list does not make sense to me. The 
list is a list of conditions that would cause the device server to clear 
the recoverable lost persistent reservation condition. There are two ways 
the condition may be cleared. 
One way is for the Replace Lost Reservation to command to succeed. 
The other way is if for some vendor specific reason the device server 
determines that the recoverable lost persistent reservation becomes 
unrecoverable. If that happens no command will get the reservation back.
Those are the two options and either option could happen first. If that is 
not case then I am not understanding the text as currently written. 
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph 
Weber
Sent: Tuesday, July 24, 2012 4:54 PM
Cc: 't10 at t10.org'
Subject: Re: REPLACE LOST RESERVATION fixes uploaded ... again ... maybe 
for the last time
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
George,
I am reasonably certain that there is a preference for successfully
processing the REPLACE LOST RESERVATION. With this in mind, I am
willing to consider the requested change, but only if the list
switches from unordered to ordered.
All the best,
.Ralph
On 7/24/2012 4:50 PM, Penokie, George wrote:
> Ralph,
>
> I have looked it over. The only suggestion I have would be to change 
item b) in the second a,b list from:
>
> b) prior to the successful processing of a PERSISTENT RESERVE OUT 
command with the REPLACE LOST RESERVATION service action, the recoverable 
lost persistent reservation becomes unrecoverable.
>
> to:
>
> b) the recoverable lost persistent reservation becoming unrecoverable.
>
> As it really matter when the reservation becomes unrecoverable. And once 
the Replace Lost Reservation occurs the a,b list instance is no longer in 
effect.
>
> Bye for now,
> George Penokie
>
> LSI Corporation
> 3033 41 St NW
> Rochester , MN 55901
>
> 507-328-9017
> george.penokie at lsi.com
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph 
Weber
> Sent: Tuesday, July 24, 2012 4:18 PM
> To: 't10 at t10.org'
> Subject: REPLACE LOST RESERVATION fixes uploaded ... again ... maybe for 
the last time
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> Based on the comments received during today's conference call,
> I have posted a new revision of the proposal that fixes the
> REPLACE LOST RESERVATION model.
>
> http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-270r3.pdf
>
> All those present on the call were satisfied with the gist of
> the changes (if not the details too), but several participants
> wanted a reasonable interval to review the final product before
> incorporation in SPC-4.
>
> With this in mind, my plan for making progress is as follows:
>
> 1) SPC-4 r36c will not include changes from 12-270; however
> 2) the changes will be incorporated in r36d unless significant
> .. complaints are received before Friday 3 August.
>
> This will give the 6 August call announced by George Penokie the
> best possible chance to inspect the REPLACE LOST RESERVATION total
> package in the posted SPC-4 r36d PDF file.
>
> All the best,
>
> .Ralph
> *
> * 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