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

Kevin D Butt kdbutt at us.ibm.com
Wed Jul 25 13:28:25 PDT 2012


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

Ralph,
My responses.
========== a =========
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.
===Answer to a======
You are correct.  I messed up here.  It should have said:
The device server shall clear a recoverable lost persistent reservation 
condition 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) the recoverable lost persistent reservation becoming an unrecoverable 
lost persistent reservation. 
========= b ============
b ...
Please explain the value of removing the word 'only' and substituting
a separate sentence that is disconnected from the a,b list.
==== Answer to b ====
To me, the phrase "that the device server shall clear only in response to:
" levies a requirement to not clear the condition except in response to 
the items listed.  I see no requirement to actually clear the condition 
but belief there is an implied one.
======= c ============
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 
========= answer to C ================
It is an attempt to provide a definition for "recoverable lost persistent 
reservation condition".  I felt it was desirable since when I first read 
the text this modifies, I was left hanging to wonder what exactly a 
"recoverable lost persistent reservation condition" is.
============= d ============
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.
============ answer to d =============
I am used to trying to follow the style guide even though it is not a 
requirement.
6.4.3.5.1 If?, then versus if?,
The verbal form ?if ? should be followed by the verbal form ?then?, 
however, the ?then? is not required if the
context of the statement is clear (e.g., If the field is set to one, the 
device may reject the command.). However, it
is always correct to include the ?then?. <<Inclusion of ?then? is 
recommended to eliminate any possible confusion.>>
I note your profound perturbation and will attempt to suppress my habit 
while responding to your proposals.
Thanks,
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:	Ralph Weber <roweber at ieee.org>
To: 
Cc:	"'t10 at t10.org'" <t10 at t10.org>
Date:	07/25/2012 12:26 PM
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:
* 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



More information about the T10 mailing list