POWER CYCLE PROXIMITY

Shafranov, Andrew Andrew.Shafranov at amd.com
Wed Feb 15 13:55:54 PST 2012


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

Hi,
A few remarks regarding the POWER CYCLE PROXIMITY paradigm;
I would like to notice that a power cycle is not necessarily means boot and
vice versa:
First, upon the warm boot a power cycle may not happen.
Then, a HDD might be powered off / on as a part of the Idle management
Thanks
Andrew
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Leonid
Podolny
Sent: Tuesday, January 31, 2012 11:00 AM
To: Penokie, George
Cc: t10 at t10.org
Subject: Re: spc4r33: persistent reservations preemtion
You are absolutely right, I forgot to say that all questions refer to
PERSISTENT RESERVE OUT: PREEMPT.
On Tue, Jan 31, 2012 at 5:29 PM, Penokie, George
<George.Penokie at lsi.com> wrote:
If I understand your questions which are not clear as they do not indicate
what commands are being issued.
If the command in your number 1 comment is  a PERSISTENT RESERVE OUT command
with RELEASE service action, then the answer to number 1 is at the end of
section 5.9.11.2 Releasing and is stated as:
If there is no persistent reservation or in response to a persistent
reservation release request from a registered I_T
nexus that is not a persistent reservation holder (see 5.9.10), the device
server shall do the following:
a) not release the persistent reservation, if any;
b) not remove any registrations; and
c) complete the command with GOOD status.
If not then I have no idea what you are asking.
Your second question is impossible to answer without knowing what command is
being issued.
The text under figure 6 in section 5.9.11.4.4 Removing registrations
describes the case for an invalid SERVICE ACTION RESERVATION KEY:
If a PERSISTENT RESERVE OUT with a PREEMPT service action or a PREEMPT AND
ABORT service action
sets the SERVICE ACTION RESERVATION KEY field to a value that does not match
any registered reservation key, then
the device server shall complete the command with RESERVATION CONFLICT
status.
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017<tel:507-328-9017>
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org>
[mailto:owner-t10 at t10.org<mailto:owner-t10 at t10.org>] On Behalf Of Leonid
Podolny
Sent: Sunday, January 29, 2012 6:12 AM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: spc4r33: persistent reservations preemtion
* From the T10 Reflector (t10 at t10.org<mailto:t10 at t10.org>), posted by:
* Leonid Podolny
<leonid.podolny at xtremio.com>
*
Good day,
The most recent draft of SPC-4 doesn't seem to address two specific
scenarios. (Even if it does address these scenarios, it probably
merits a clarification, because I just can't find a definite answer).
I fail to understand the desired behavior in the following cases:
1) There is no existing persistent reservation and SERVICE ACTION
RESERVATION KEY is zero. Should the server clean _all_ registrations
or return RESERVATION CONFLICT?
2) There is an existing "All Registrants" reservation and the SERVICE
ACTION RESERVATION KEY equals the registration key of a requesting
nexus. Should the server remove the registration of the requesting
nexus (w/o creating a new reservation) or should it remove
registrations of all matching nexuses except for the requesting nexus?
If the answer is the latter, what happens with the reservation?
In addition, in figure 6, the server is required to validate the
SERVICE ACTION RESERVATION KEY (the second rhombus at the top left
corner of the figure). What is the criteria of the validity of the
SERVICE ACTION RESERVATION KEY?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to
majordomo at t10.org<mailto:majordomo at t10.org>



More information about the T10 mailing list