Re: [storm] SPC-2 reserve/release: Proposed text

[Mallikarjun Chadalapaka <[e-mail]>]

Hi David, thanks for the first draft. I have a few quick comments.
1) IMHO, opening sentence of "I_T nexus state includes reservation state" is a little too broad, particularly since you go on to spell out two kinds of reservation state. So it can easily be misconstrued as suggesting that I_T nexus state includes persistent reservation state - however the following text correctly states that persistent reservations are unaffected by I_T nexus loss. Persistent reservation state is a device server state, but it is held by one or more I_T nexus(es).
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.
3) Should use Time2Retain+Time2Wait, not Default Time2Wait
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.
5) Should articulate the underlying linkage between Time2Retain (an iSCSI concept), and the reserve/release state (a SCSI state).

Thanks.

Mallikarjun


Here is the revised text addressing the above comments:

  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 in [SPC3] and SHOULD NOT be
  used; persistent reservations SHOULD be used instead.  

  The reservation state for persistent reservations is 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 implementation, 
  the implementations should consider the I_T nexus state to include SCSI reserve/release 
  reservation state.  The preferred implementation approach is to preserve reserve/release
  reservation state along with other I_T nexus state until  iSCSI session
  reinstatement (Section 6.3.5) or continuation via session continuation (Section 6.3.6).

  Two additional considerations are applicable to reserve/release reservations:

  - When the original iSCSI session, i.e. I_T nexus, is not reinstated 
     or continued by the initiator and if the target retains reserve/release 
     reservation state for an extended period of time, initiator may be 
     forced to issue a Target Cold Reset, or a Target Warm Reset, 
     or a Logical Unit Reset action (Section 11.5) in order to remove that 
     reservation state. So targets should apply the session-global Time2Wait
     and Time2Retain timeout values (Section 7.5) to manage the reserve/release 
     reservation state along with the rest of the iSCSI session state.

  - 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], and the discussion in Annex B regarding how to apply 
      persistent reservations to realize the reserve/release reservation semantics.



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ralph Weber
Sent: Tuesday, September 25, 2012 9:58 AM
To: [e-mail]
Subject: Re: [storm] SPC-2 reserve/release: Proposed text

David,

I believe a paragraph break is needed as shown in the following:

>   Reserve/release reservations are obsolete [SPC3] and SHOULD NOT be
>   used; persistent reservations SHOULD be used instead.  [break] The 
> I_T Nexus
>   state for persistent reservations is generally required ...

The chances of confusion are high when a paragraph that begins with a discussion of reserve/release reservations continues into the persistent reservations territory.

Also please be aware that Annex B of SPC-4 describes the means by which the use of reserve/release reservations can be adapted to employ persistent reservations. I am not sure this an appropriate informative reference for an RFC, but it seems worthy of mention on this reflector.

All the best,

.Ralph

On 9/25/2012 10:44 AM, Black, David wrote:
> <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
> [phone]              FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
>
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>
>

_______________________________________________
storm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/storm