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

[Ralph Weber]

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Kevin,
a ...
If I have visually pasted the parts of one change together correctly,
they you are saying:
> *The *device server shall clear *a recoverable lost persistent 
> reservation condition *only in response to: ...
> *if *the recoverable lost persistent reservation becomes *an 
> *unrecoverable*lost persistent reservation*. 
This does not look like English to me.
b ...
Please explain the value of removing the word 'only' and substituting
a separate sentence that is disconnected from the a,b list.
c ..
What is the purpose of the following verbosity in a situation where
a single sentence should suffice?
> 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 
d ...
I am profoundly disturbed by the implied (but non existent) T10
Style *requirement* represented by the purple standalone "then" in
the above change. Such uses of "then" shall not appear in proposals
I write, and when discovered they will be editorially expunged from
SPC-4.
All the best,
.Ralph
On 7/25/2012 11:36 AM, Kevin D Butt wrote:
> 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
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org