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

["Black, David" <[e-mail]>]

Julian,

> The text in 4.4.3 states the obvious (there is no other speced method for
> continuation or reinstatement). Moreover if the session is reinstated
> after time2wait you create a need for a UA (or at least suggest one) and that
> was not there.

The UAs are courtesy of SAM-3 (and SAM-4).  To encompass systems that may
not deliver these UAs and situations in which they don't occur (e.g., the
target doesn't recognize what happened as nexus reestablishment,
independent of what the initiator thinks it's doing) I think the text
should be rephrased as:

     If a Unit Attention condition results from session reestablishment,
     the specific Unit Attention condition indicates whether nexus state
     was preserved, see Section 6.3.4 of [SAM4].

> 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.

Unfortunately, SPC-2 is sufficiently imprecise on this subject that such an
implication is at best a "preferred implementation approach".  It's not a
requirement that can be safely stated in any stronger fashion without the
risk of rendering existing implementations non-compliant.

> The new text you suggest to 4.4 is merely a best practices recommendations and
> will need additions once the new "locking" through compare-and-swap get in
> widespread use.

It's definitely best practices recommendations - no argument there.

For context, what Julian is referring to is use of the COMPARE AND WRITE command
that performs an atomic operation at the target instead of using RESERVE and RELEASE
to create a critical section at the initiator based on read and write commands.

COMPARE AND WRITE is in use - a sentence mentioning that command could be added,
although this best practices text is aimed primarily at uses of reserve/release
for long-term reservations.  I think there's an implicit "when a reservation is
the desired behavior" implication to the "persistent reservations SHOULD be used
instead" text that I don't think needs to be made explicit.  OTOH, that "SHOULD"
could be changed to a "should", or it might be even better to rewrite that text
as: 

	persistent reservations are suggested as an alternative, see Annex B
	of [SPC4].

In contrast, "SHOULD NOT be used" is clearly justified for reserve/release
reservations by [SPC3].

Thanks,
--David


> -----Original Message-----
> From: Julian Satran [mailto:[e-mail]]
> Sent: Wednesday, September 26, 2012 10:25 PM
> To: Black, David
> Cc: [e-mail]
> Subject: Re: [storm] SPC-2 reserve/release text - version 6
> 
> 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