[storm] SPC-2 reserve/release: Proposed text - version 3
"Black, David" <david.black@emc.com> Tue, 25 September 2012 19:53 UTC
Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5838A21F85AF for <storm@ietfa.amsl.com>; Tue, 25 Sep 2012 12:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxEbPIkbw-Xe for <storm@ietfa.amsl.com>; Tue, 25 Sep 2012 12:53:57 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6699821F85AC for <storm@ietf.org>; Tue, 25 Sep 2012 12:53:57 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8PJrudJ012604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Tue, 25 Sep 2012 15:53:56 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for <storm@ietf.org>; Tue, 25 Sep 2012 15:53:42 -0400
Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8PJre2a016532 for <storm@ietf.org>; Tue, 25 Sep 2012 15:53:40 -0400
Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Tue, 25 Sep 2012 15:53:40 -0400
From: "Black, David" <david.black@emc.com>
To: "storm@ietf.org" <storm@ietf.org>
Date: Tue, 25 Sep 2012 15:53:39 -0400
Thread-Topic: SPC-2 reserve/release: Proposed text - version 3
Thread-Index: Ac2bNKguGPJW+zTbTTC2uDGdWEV2OAAGl/vwAAGNYXA=
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DE7952E@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [storm] SPC-2 reserve/release: Proposed text - version 3
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Sep 2012 19:53:58 -0000
version 3: Responding to Mallikarjun's comments (plus some more edits) - > 1) IMHO, opening sentence of "I_T nexus state includes reservation state" > is a little too broad, I removed that sentence, removed I_T Nexus from new section title and tweaked the persistent reservation text to talk about state in general as opposed to I_T Nexus state in particular. > 2) Hard reset is not an LU reset - it is either an iSCSI Target Warm Reset, > or (more likely) an iSCSI Target Cold Reset. In either case, any of the > three resets should clear the reserve/release state. I removed the word "hard" - as you noted, an LU reset is sufficient to remove a reserve/release reservation. > 3) Should use Time2Retain+Time2Wait, not Default Time2Wait Brilliant minds think alike - I got to that one in version 2 ;-). > 4) Session recovery does not necessarily preserve the I_T nexus state > (recovery may not occur within Time2Wait+Time2Retain, and may not use > the same ISID when it occurs), but session reinstatement and session > continuation certainly should. I changed "session recovery" to "session reinstatement". > 5) Should articulate the underlying linkage between Time2Retain > (an iSCSI concept), and the reserve/release state (a SCSI state). I believe I also got to that one in version 2. version 2: I moved a paragraph break in response to Ralph's comments, and rewrote the first additional consideration to reference the connection timeout values in general. I also found some minor problems that need correction in Section 4.6.3.3 (see end of this message). <WG chair hat off> Here's an initial attempt to propose text to deal with the reserve/ release topic in the consolidated iSCSI draft. Please comment, correct, suggest edits, etc. The new text would be a new section 4.4.3.2 that would follow 4.4.3.1: 4.4.3.1. I_T Nexus State Certain nexus relationships contain an explicit state (e.g., initiator-specific mode pages) that may need to be preserved by the device server [SAM2] in a logical unit through changes or failures in the iSCSI layer (e.g., session failures). In order for that state to be restored, the iSCSI initiator should reestablish its session (re-login) to the same Target Portal Group using the previous ISID. That is, it should perform session recovery as described in Chapter 6. This is because the SCSI initiator port identifier and the SCSI target port identifier (or relative target port) form the datum that the SCSI logical unit device server uses to identify the I_T nexus. ------------------------------- First, for clarity, the following change should be made in the above 4.4.3.1 text to better identify the recovery mechanism: OLD That is, it should perform session recovery as described in Chapter 6. NEW That is, it should recover the session via connection reinstatement as described in Section 6.3.4. END I believe that a lower-case "should" remains appropriate for this text. ----------------------------------- NEW TEXT (second draft): 4.4.3.2. Reservations There are two reservation management methods defined in the SCSI standards, reserve/release reservations, based on the RESERVE and RELEASE commands [SPC2], and persistent reservations, based on the PERSISTENT RESERVE IN and PERSISTENT RESERVE OUT commands [SPC3]. Reserve/release reservations are obsolete [SPC3] and SHOULD NOT be used; persistent reservations SHOULD be used instead. State for persistent reservations is generally required to persist through changes and failures at the iSCSI layer that result in I_T Nexus failures, see [SPC3] for details and specific requirements. In contrast, [SPC2] does not specify detailed persistence requirements for reserve/release reservation state after an I_T Nexus failure. Nonetheless, when reserve/release reservations are supported by an iSCSI target, the preferred implementation approach is to preserve reserve/release reservation state along with other I_T Nexus state for iSCSI session reinstatement or session continuation via connection reinstatement. Two additional caveats apply to reserve/release reservations: - Retention of reserve/release reservation state for an extended period of time after connection failure may require a reset (e.g., LOGICAL UNIT RESET, see section 11.5) in order to remove that reservation state when connection reinstatement is not performed. When reserve/release reservation state is retained after connection failure, the need for such resets may be reduced via suitable selection of the Time2Wait and Time2Retain timeout values that control connection state retention duration (see Section 7.5). - Reserve/release reservations may not behave as expected when persistent reservations are also used on the same logical unit; see the discussion of "Exceptions to SPC-2 RESERVE and RELEASE behavior" in [SPC4]. ----------------------- Reference impacts: both [SPC2] and [SPC3] need to be normative references, but [SPC4] can be an informative reference. ------------------------- I deliberately used "the preferred iSCSI implementation approach" wording for reserve/release reservation state preservation requirements, as SPC-2 is vague on this topic and I'm rather uncomfortable with placing a requirement as strong as a "SHOULD" on an obsolete mechanism that "SHOULD NOT" be used. --------------- New problem in Section 4.6.3.3 - in this text: The Logout response indicates that the connection or session cleanup is completed and no other responses will arrive on the connection (if received on the logging out connection). In addition, the Logout Response indicates how long the target will continue to hold resources for recovery (e.g., command execution that continues on a new connection) in the text key Time2Retain and how long the initiator must wait before proceeding with recovery in the text key Time2Wait. Time2Wait and Time2Retain are not text keys - they're binary fields in the Logout Response PDU. Two changes are in order: - "text key Time2Retain" -> "Time2Retain field" - "text key Time2Wait" -> "Time2Wait field" Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm
- [storm] SPC-2 reserve/release: Proposed text - ve… Black, David