FCP-2 problem

Zeitler, Carl Carl.Zeitler at COMPAQ.com
Sun Jun 18 17:48:18 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* "Zeitler, Carl" <Carl.Zeitler at compaq.com>
*
The Initiator would see the REC sent by the Target on lack of receipt of
FCP_CONF.  I was assuming your scenario of requiring FCP_CONF.

-----Original Message-----
From: Matt Wakeley [mailto:matt_wakeley at agilent.com]
Sent: Friday, June 16, 2000 6:03 PM
To: Fibre Reflector; T10 Reflector
Subject: Re: FCP-2 problem


*
* From the fc reflector, posted by:
* Matt Wakeley <matt_wakeley at agilent.com>
*
"Zeitler, Carl" wrote:

> *
> * From the fc reflector, posted by:
> * "Zeitler, Carl" <Carl.Zeitler at compaq.com>
> *
> Have been on vacation so missed out on all the fun.  I believe Matt's
> solution works.

>  Another solution is to Abort the Exchange.  In other words,
> if the Initiator receives an REC for any OX_ID currently in use, the
> Initiator aborts the Exchange currently using the ambiguous OX_ID.

Carl, why would the initiator receive an REC?

>  This is
> a double error situation and had thought that we had agreed to do Abort
> Exchange in double error situations at the last meeting.

I don't consider this a "double" error condition. A double error condition
occurs when an error occurs during error recovery.  In the cases described,
recovery hasn't started yet.  In fact, we are still trying to figure out how
to
detect the error...

-Matt Wakeley
Agilent Technologies

> (It could be a
> single error situation, where FCP_CONF is lost and the REC from the Target
> and the new Command with the same OX_ID from the Initiator pass each
other.
> This could be mitigated by cycling OX_ID usage.)
>
> If there is no FCP_CONF, then the only solution I can think of is to not
> reuse the OX_ID, as previously suggested, for >R_R_TOV.  However this
> requires that the Target discard the context after R_R_TOV or you have the
> same problem.  So the Target would have to guarantee that it shall discard
> the context(a Class 3 Recovery Qualifier?) between R_R_TOV and R_R_TOV +
> E_D_TOV(?).  And the Initiator shall not reuse the same OX_ID for R_R_TOV
+
> E_D_TOV(?).
>
> Working with only half a deck (no Class 2 ACKS)in error recovery
situations
> is a challenge.
>
> Regards, Carl
>
> Carl Zeitler
> Compaq Computer Corporation
> MS 150801, 20555 SH249, Houston, TX 77070
> Phone:281-518-5258 Fax: 281-514-5270
> E-Mail: Carl.Zeitler at compaq.com
>
> -----Original Message-----
> From: Matt Wakeley [mailto:matt_wakeley at agilent.com]
> Sent: Wednesday, June 14, 2000 10:39 PM
> To: Fibre Reflector; T10 Reflector
> Subject: Re: FCP-2 problem
>
> *
> * From the fc reflector, posted by:
> * Matt Wakeley <matt_wakeley at agilent.com>
> *
> > >Does use of FCP_CONF_REQ on the response resolve the issue? The target
> will
> > >release the resource after receiving FCP_CONF and the OXID is free. The
> REC
> > >sent after the lost command will then not receive an ACC, as the OXID
is
> > >invalid.
>
> > I had kicked this idea around too. This makes it better, but not
perfect.
> The
> > issue I came up with is:
> >
> > If the FCP_CONF and the second command are dropped, you have the same
> problem.
> > The REC will end up recovering the first command, while the initiator
> thinks the
> > second command has been completed.
>
> One way to do this is, for commands that do not involve data transfer,
> require that
> the target request FCP_CONF, and require the initiator perform an REC
after
> sending
> the FCP_CONF, to verify that the FCP_CONF got there before reusing the
> OX_ID.  Ugly,
> but I think it'll work if we don't want to change the REC or SRR payloads.
>
> McGRATH:
> >  So another solution is to make sure you
> >  do not reuse an OX_ID until you are really sure that this sort of
problem
> >  cannot occur.
>
> And how do you determine that?
>
> > In this case, using two values in alteration would work OK.
>
> I don't think so.  Consider the following:
>
> Initiator sends SPACE command (OX_ID=1).
>
> SPACE command completes, and target sends response (and keeps status of
the
> exchange
> around).
> <just for completeness, let's say the FCP_RSP requested a FCP_CONF, which
> the
> initiator sent, but was lost, so the target is retaining the status of
> OX_ID=1>
>
> Initiator sends WRITE command (OX_ID=2) (target is performing command
> queuing, so
> the status of exchage with OX_ID=1 is not deallocated)
>
> WRITE command completes, and target sends response (and keeps status of
the
> exchange
> around).
>
> Initiator sends SPACE command (OX_ID=1), but the command is lost... same
> issue as
> before. The target still retains the state of the original space command.
>
> -Matt Wakeley


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list