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

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

Fred,

> If state is retained (it's an old "I" reconnecting), then which UA is defined
> by SAM-3.
> 
> If state is not retained (it's a new "I"), then the UA is defined by SAM-3.
>
> Since both old "I"s and new "I"s result in the "IF" condition being true, what
> is the condition that would make the "IF" false?

You almost answered your own question ;-).

The answer is .... (drum roll) ... a target implementation based on RFC 3720
SAM-2, although I would hope that such implementations at least picked
up RFC 5048's changes.  

The I_T Nexus Loss concept on which this UA discussion is based is part of
the SCSI events and event notifications model that was introduced in SAM-3,
but neither RFC 3720 nor RFC 5048 references SAM-3.

There were definitely implementations of iSCSI based on SAM-2 - I agree with
Julian that we should *not* be introducing a UA requirement in this draft
that might break such implementations.

Thanks,
--David

> -----Original Message-----
> From: Knight, Frederick [mailto:[e-mail]]
> Sent: Friday, September 28, 2012 8:38 AM
> To: Julian Satran
> Cc: Black, David; [e-mail]
> Subject: RE: [storm] SPC-2 reserve/release text - version 6
> 
> OK, that's what I thought.
> 
> If state is retained (it's an old "I" reconnecting), then which UA is defined
> by SAM-3.
> 
> If state is not retained (it's a new "I"), then the UA is defined by SAM-3.
> 
> Since both old "I"s and new "I"s result in the "IF" condition being true, what
> is the condition that would make the "IF" false?
> 
> That "IF" language allows a target to loose state and not deliver any UA.
> 
> 	Fred
> 
> 
> -----Original Message-----
> From: Julian Satran [mailto:[e-mail]]
> Sent: Friday, September 28, 2012 2:03 AM
> To: Knight, Frederick
> Cc: Black, David; [e-mail]
> Subject: Re: [storm] SPC-2 reserve/release text - version 6
> 
> There is no such thing. And the reason the timeout is there is to limit the
> amount of state the targets have to keep. A target may choose to accept very
> large timeouts and then do what you wanted done but beyond that only the
> power-up ua is required.
> 
> julo
> 
> Sent from my iPad
> 
> On 28 בספט 2012, at 00:29, "Knight, Frederick" <[e-mail]>
> wrote:
> 
> > I would think if the ISID is not recognized as an old one, then it must be
> recognized as a new one.  If it is a new one, then it will get a UA: 29/00
> reflecting the first access after power on from the "new" initiator.
> >
> > Is there something other than new or old?  Is there such a thing as a
> middle-aged initiator?
> >
> >    Fred
> >
> > -----Original Message-----
> > From: Black, David [mailto:[e-mail]]
> > Sent: Thursday, September 27, 2012 11:56 AM
> > To: Knight, Frederick
> > Cc: [e-mail]
> > Subject: RE: [storm] SPC-2 reserve/release text - version 6
> >
> > Fred,
> >
> > The problem is not that the device does not raise a UA, it's that the UA may
> never be delivered.
> >
> > A summary of how this can happen is that the new connection with the same
> ISID may not be recognized as reinstating or continuing the session at the
> target if the timeouts have expired - the UA gets established, but nobody
> shows up to pick it up in time, so the UA is discarded along with the rest of
> the session state and the target fails to recognize the initiator's subsequent
> ISID reuse even though the initiator believes that it's re- establishing the
> session.
> >
> > This is further complicated by the UA that indicates nexus state
> preservation not being specified in SAM-2.
> >
> > Thanks,
> > --David
> >
> >
> >> -----Original Message-----
> >> From: Knight, Frederick [mailto:[e-mail]]
> >> Sent: Thursday, September 27, 2012 11:11 AM
> >> To: Black, David; Julian Satran
> >> Cc: [e-mail]
> >> Subject: RE: [storm] SPC-2 reserve/release text - version 6
> >>
> >> I afraid I have to contest a little on this - if I understand this
> >> discussion correctly.
> >>
> >> If a SCSI device loses any state and does not raise a UNIT ATTENTION,
> >> then it is BROKEN.  It is not a matter of anything in iSCSI (3720); I
> >> think SAM and SPC are pretty clear on this.  If there is no UNIT
> >> ATTENTION, then state SHALL be preserved; otherwise, all sorts of
> >> stuff will never work (mode page settings, RESERVE commands, all sorts of
> stuff).
> >>
> >> Is someone really suggesting that some devices will drop state and
> >> NOT tell the host, and somehow that it is OK to do that?
> >>
> >> The suggest rewording says this is possible.
> >>
> >>    Fred
> >>
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Black, David
> >> Sent: Thursday, September 27, 2012 10:47 AM
> >> To: Julian Satran
> >> Cc: [e-mail]
> >> Subject: Re: [storm] SPC-2 reserve/release text - version 6
> >>
> >> 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
> >>
> >> _______________________________________________
> >> storm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/storm
> > _______________________________________________
> > storm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/storm