[T11.3] Re: FCP-3: Obsolete FCP_DL and FCP_BIDIRECTIONAL_DL
joe at lingua-data.com
Fri Oct 1 15:54:04 PDT 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* "Joe Breher" <joe at lingua-data.com>
There are a near-infinite number of ways that an Initiator Port can sabotage
an FCP transfer. In many such cases, it is elementary how such sabotage can
be averted. I would suggest that this is one such case. An initiator that
mis-sets the FCP_DL value is likely to die a quick death in the marketplace.
Speaking as a (former) tape guy, I don't see the possiblity of mis-valued
FCP_DL fields to be a significant issue.
OTOH, architecturally, FCP_DL works at an entirely different layer than
whatever transfer length is set forth in the CDB. The FCP layer should not
be required to crack a CDB in order to determine how many bytes are to be
transferred. The contents of the CDB belong to the Device Server, not the
Lastly, as a practical matter, it seems to me that obsoleting FCP_DL would
lead to large-scale interoperability headaches. Old intiators setting it,
with new targets ignoring it would not seem to be much of a problem, but
what of the converse? The target would have to fail the exchange every time.
For all these reasons, I believe it would be folly to obsolete FCP_DL.
> -----Original Message-----
> From: t11_3-bounce at mailman.listserve.com
> [mailto:t11_3-bounce at mailman.listserve.com] On Behalf Of
> Jim.Coomes at seagate.com
> Sent: Friday, October 01, 2004 3:34 PM
> To: 'Robert Snively'; phil.colline at dothill.com; david_peterson at cnt.com
> Cc: t10 at t10.org; t11_3 at mail.t11.org
> Subject: [T11.3] Re: FCP-3: Obsolete FCP_DL and FCP_BIDIRECTIONAL_DL
> This issue of obsoleting FCP_DL and FCP_BIDIRECTIONAL_DL was
> raised due to a change in processing these fields in FCP-3.
> The function of the FCP_DL field in FCP and FCP-2 required
> targets to do truncated transfers, set flags and return
> residual counts when the CDB length and the FCP_DL field did
> not agree. Disk drive and RAID vendors have implemented the
> checking and transfer behavior to this requirement. This has
> lead to many test conditions for compliance to the required behaviors.
> Tape vendors find the truncated transfers unacceptable.
> Recovery from a partial transfer could easily require a
> repositioning of the tape.
> In FCP-3, the recommended response ( a "should") to FCP_DL
> and FCP_BIDIRECTIONAL_DL field values that do not match the
> expected transfer length identified in the CDB is to fail the
> command with no transfer and check condition.
> As currently documented in FCP-3, disk drive and RAID vendors
> "should" fail commands with FCP_DL and FCP_BIDIRECTIONAL_DL
> field values considered in error.
> Is failing the command acceptable to current implementation?
> To Unsubscribe: mailto:t11_3-request at mail.t11.org?subject=unsubscribe
* 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