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

[Julian Satran <[e-mail]>]

David,

The text in 4.4.3 states the obvious (there is no other speced method for continuation or reinstatement). Moreover if the the session is reinstated after time2wait you create a need for a UA (or at least suggest one) and that was not there. Just stating that creation/continuation of a session done according 6.x includes preservation of reserve/release state -that was already there implied by conformance to spc2 and the relation between it nexus and session.

The new text you suggest to 4.4 is merely a best practices recomendations and will need additions once the new "locking" through compare-and-swap get in widespread use.
If instead we refrain from stating anything specific and state that target should maintain whatever state is required by SPC while a session is continued and may discard state when a session is terminated and may indicate that it discarded state through a ua you are on safer ground and do not create new requirement.

Sent from my iPad

On 27 בספט 2012, at 00:25, "Black, David" <[e-mail]> wrote:

> Here's where I think we've arrived (I've made a few minor editorial
> tweaks to what's been discussed).  Despite all the detailed discussion,
> I think this version 6 comes close to Julian's suggestion that:
> 
>> i would mention only that the state that must be maintained while
>> the session is maintained includes the reserve/release and leave it to that.
> 
> Although we can't actually say "must" as that would be a new requirement,
> and implementations differ in what they do about reserve/release
> reservation state.  The current language characterizes retention of
> that state as the "preferred implementation approach".
> 
> Beyond that, I think the two additional caveats about reserve/release
> reservations (possible need for a reset, potentially unexpected
> interaction with persistent reservations, see below) are useful to include.
> 
> -----------------------------------------
> 
> [1] For clarity, the following change should be made in
> 4.4.3.1:
> 
> OLD
>  That is, it should perform session recovery as
>  described in Chapter 6.
> NEW
>  That is, it should reinstate the session via iSCSI session
>  reinstatement (Section 6.3.5) or continue via session
>  continuation (Section 6.3.6).
> END
> 
> [2] Add the following sentence to the end of 4.4.3.1:
> 
>     The specific Unit Attention condition that results from session
>     reestablishment indicates whether nexus state was preserved,
>     see Section 6.3.4 of [SAM4].
> 
> [3] NEW TEXT:
> 
> 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 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 for iSCSI session
>  reinstatement (see Section 6.3.5) or session continuation
>  (see Section 6.3.6).
> 
>  Two additional caveats apply to reserve/release reservations:
> 
>  - When connection failure causes the iSCSI session to fail, and
>      the session is not reinstated or continued, target retention
>      of that session's reserve/release reservation state may
>      require an initiator to issue a reset (e.g., LOGICAL UNIT RESET,
>      see section 11.5) in order to remove that reservation 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].
> 
> 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