[storm] SPC-2 reserve/release: Proposed text
"Black, David" <david.black@emc.com> Tue, 25 September 2012 15:44 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 2127421F86AD for <storm@ietfa.amsl.com>; Tue, 25 Sep 2012 08:44:52 -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 FTkTMFbjn5mu for <storm@ietfa.amsl.com>; Tue, 25 Sep 2012 08:44:51 -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 60FDF21F87D3 for <storm@ietf.org>; Tue, 25 Sep 2012 08:44:51 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8PFinDg026504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Tue, 25 Sep 2012 11:44:49 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for <storm@ietf.org>; Tue, 25 Sep 2012 11:44:34 -0400
Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8PFiYvv021948 for <storm@ietf.org>; Tue, 25 Sep 2012 11:44:34 -0400
Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Tue, 25 Sep 2012 11:44:34 -0400
From: "Black, David" <david.black@emc.com>
To: "storm@ietf.org" <storm@ietf.org>
Date: Tue, 25 Sep 2012 11:44:32 -0400
Thread-Topic: SPC-2 reserve/release: Proposed text
Thread-Index: Ac2bNKguGPJW+zTbTTC2uDGdWEV2OA==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DE7946D@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
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 15:44:52 -0000
<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 (first draft): 4.4.3.2. I_T Nexus State: Reservations The state of an I_T Nexus includes SCSI reservation state. 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. The I_T Nexus 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 - 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 recovery or continuation via connection reinstatement. Two additional caveats apply to reserve/release reservations: - Retention of reserve/release reservation state for an extended period of time may require a hard reset (e.g., LOGICAL UNIT RESET, see section 11.5) in order to remove that state when connection reinstatement is not performed. The DefaultTime2Wait value can be used to limit this retention time period (see section 13.15). - 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. 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] SPC-2 reserve/release: Proposed text Black, David
- Re: [storm] SPC-2 reserve/release: Proposed text Ralph Weber
- Re: [storm] SPC-2 reserve/release: Proposed text Mallikarjun Chadalapaka