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

["Knight, Frederick" <[e-mail]>]

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