[T11.3] FCP-3 Work Item #4
Paul.A.Suhler at certance.com
Paul.A.Suhler at certance.com
Wed Sep 24 16:06:13 PDT 2003
INCITS T11.3 Mail Reflector
Hi, Horst & Bob.
Thanks for the input.
The problem that I still have to solve is that for a write with FCP_DL too
small, we absolutely cannot write to the medium less data than the CDB
specifies and then return GOOD status. I would never trust the HBA driver
to see the underrun indication and report a failure to the application so
that it would be aware of the partial write.
As a variant on #2, what would you say to the following? The target could
move FCP_DL bytes, discard it all, and then report CHECK CONDITION. It's
certainly inefficient, but that wouldn't matter because we're dealing with
a broken driver, a rare occurrence as you point out.
Would any of the other tapeheads care to wade in on this?
<rsnively at brocade To: "'Paul.A.Suhler at certance.com'" <Paul.A.Suhler at certance.com>, t10 at t10.org,
.com> t11_3 at mail.t11.org
Sent by: cc:
owner-t10 at t10.org Subject: RE: [T11.3] FCP-3 Work Item #4
Horst is right.
The proper view of this is that the FC-4 layer protocol
defined by FCP has FC components that define the permitted
Fibre Channel and application behavior and SAM compliant
components that define the permitted SCSI behavior.
Buffer allocations can routinely be made with incomplete
knowledge of the expected SCSI data length, and it is these
buffer allocations that must protect themselves and warn of their
violation. FCP_DL is the Fibre Channel mechanism for that.
In the tape write case you describe, the buffer length is the SCSI
data length, and FCP_DL will always exactly equal the data to
be transferred. However, this is not a general behavior.
Reads are the most dangerous, since they may transmit data
into other buffers as the Data Buffer Pointer increments
beyond the expected limits.
Admittedly, most HBAs on most ordinary SCSI devices doing
nothing special will find FCP_DL violations only during
I believe that the present text is still valid and does not
need to be modified.
I believe your suggestion 1 is not advisable because it
requires posting a protocol failure before the protocol
has been violated.
I believe your suggestion 2 is not advisable because it
forces the SCSI layer to detect potential (but not yet
definite) violations of the transmission protocol.
I believe your suggestion 3 is not advisable because it
conflicts with previous successful FCP implementation.
ADT is not a good counter-example, since it uses a simpler
protocol with a private physical layer and a private
layering structure. FCP on the other hand is one of many
protocols that a Fibre Channel HBA supports, each with its
own mechanism for managing FC buffering and transfers.
> -----Original Message-----
> From: Paul.A.Suhler at certance.com [mailto:Paul.A.Suhler at certance.com]
> Sent: Tuesday, September 23, 2003 11:27 AM
> To: t10 at t10.org; t11_3 at mail.t11.org
> Subject: [T11.3] FCP-3 Work Item #4
> INCITS T11.3 Mail Reflector
> I don't recall an in-depth discussion of this item at the
> meeting and the
> minutes aren't out yet, so I thought that I'd raise a question here.
> The issue is what to do with an FCP_CMND IU in which the CDB
> specifies a
> data transfer longer than FCP_DL:
> 4) - clause 9.3
> ... The target shall never request or deliver data outside
> the buffer
> length defined by FCP_DL. If the command requested that data beyond
> FCP_DL be transferred, the FCP_RSP IU shall contain the
> bit set to one. The command is completed normally except that data
> beyond the FCP_DL count shall not be transferred and that the
> appropriate overrun condition is presented. See 9.4.4.
> How can the command ever request that data beyond FCP_DL
> be transferred?
> Maybe this would be for example, when a variable length read type
> command is issued to a tape device that results in data
> larger than the
> provided FCP_DL?
> I'd argue that the last case should not occur. The HBA
> driver should be
> able to set FCP_DL correctly.
> Nevertheless, a target must handle the error. My main
> concern is a write
> to tape where FCP_DL is too short. I believe that
> transferring and writing
> less data than the CDB specifies would be much worse than
> simply rejecting
> the command. I see three possible solutions:
> 1. Reject the command with a transport-level error, i.e.,
> RSP_CODE != 0.
> Perhaps 02h, "FCP_CMND fields invalid"
> 2. Reject the command with a status of Check Condition /
> Illegal Request
> and an appropriate ASC
> 3. Obsolete the FCP_DL field and ignore it, letting the target always
> transfer the amount of data specified in the CDB. We're
> taking this path
> in ADT by not putting in such a field.
mailto:t11_3-request at mail.t11.org?subject=unsubscribe
More information about the T10