matt_wakeley at agilent.com
Wed Jun 14 20:39:22 PDT 2000
* From the T10 Reflector (t10 at t10.org), 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
> 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.
> 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
<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
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.
* 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