From:
owner-t10@t10.org [mailto:owner-t10@t10.org] On
Behalf Of David Peterson
Sent: Monday, May 01, 2006 2:23 PM
To: t10@t10.org; t11_3@t11.org
Subject: FCP-4: Items for
discussion
Howdy,
Below is an email thread from Claudio that was discussed a
bit at the last FCP-4 working group meeting:
I please ask you to discuss in the FCP-4
WG the possibility to mandate continuous increasing SEQ_CNT in FCP-4. Relying
on it greatly simplifies the detection of a missing Sequence and consequently
simplifies error recovery, but today is optional in FCP-x (while is mandated by
IP over FC and is going to be mandated by FC-SATA).
Additional items for FCP-4 discussion follows (all due to
doubts submitted to me...):
- Bidirectional Commands: I think we need to count bytes for
both data-in and data-out. Which of these two counters should be put in the
FC4VALUE field of the REC ELS?
Wouldn’t
that be dependant on the type of command? FCP read or write types. The device
knows the current command type.
- Data Overlay: the FCP-3 definition of data overlay says
"see SAM-3", but SAM-3 says nothing on data overlay.
I would say
that EMDP should be disabled cause with the end to end data protection I do not
think you can even enable this option because the DIFs would get corrupted
would they not?
- Data Overlay: In which way could it be possible detecting
a missing Sequence when data overlay is used and continuously increasing
SEQ_CNT is not used? (it seems to us that there is no way, but others may have
a different opinion...).
I agree, I think
there is no possible way, at least real-time as the data is being streamed in. At
FCP response time the overrun/underrun and residual length would cause a re-execution
of the command.
- Data Overlay: how can the FC4VALUE counters can be
accurate when data overlap (i.e., how to avoid to count twice the overlapping
data)?
I would think
that the ability to resend data blocks already sent was discussed in the
specification as a bad thing. If not then I believe the only way to catch a
misbehaving target would be to track the data blocks already received and keep
track of the holes left behind. The device would also have to track the resent
data and not include the resent data as data received to satisfy a read
command.
The members of the working group came to no real
concensus/resolution per the questions and would like to open up the discussion
to the T10/T11 commitees, specifically making Continuously Increasing SEQ_CNT a
requirement for FCP-4.
Making this a requirement would be a much need improvement,
and one that has been needed for a while.
Regarding Continuously Increasing SEQ_CNT:
We have discussed requiring Continuously
Increasing SEQ_CNT during each previous FCP-x standard
development efforts and folk opted to not specify it as a requirement
since some vendors did not yet fully support it. We may have now moved past
that issue.
Regarding Bidirectional Commands:
FCP-3 states: "Sequence level error recovery as
described in 12.4 shall not be used for bidirectional SCSI commands." So
the question regarding the FC4VALUE field is moot until if/when we want to
support FCP-x error detection and recovery for bidirectional commands.
Regarding Data Overlay:
The reference to SAM-3 is not intended to refer the reader
to SAM-3 for data overlay, but since it is outside the sentence this is what it
means. The reference will be removed since it provides value in this
context (i.e., the intent was to refer the reader to SAM-3 for application
client buffer offset but that is already covered).
The other two questions are vendor implementation specifc in
my mind, others may share if they wish...
Thanks...Dave
(no disclaimer)