[T11.3] Re: FCP-3: Obsolete FCP_DL and FCP_BIDIRECTIONAL_DL

Robert Snively rsnively at Brocade.COM
Sun Oct 3 20:18:33 PDT 2004


I suppose that the choice of not executing the command is
always available, but the architecture strongly encourages
completing the command, especially of the FCP_DL is "too long".
One kind of thing that would do this would be a command
truncated because of a correction failure many blocks into
the transfer.  The command would complete with Check
Condition and appropriate error status, but with many blocks
successfully transferred.  Another would be where large buffers
were normally laid aside by the operating system,
but the command did not require all
the allocated buffer space.  I believe the "should"
mentioned by Jim should be changed to a "may" or a "should not".

I believe that the present FCP-2 behavior is correct for
the great majority of applications, including tapes.
The only concern I see that is valid and may require
additional attention is the inability of some operating
systems to manage protocol related conditions.  That=20
inability requires the presentation of new pseudo Check
Conditions to carry the protocol error information to the system logs.
In the last meeting, a preliminary proposal was presented
to address that. =20

Bob

> -----Original Message-----
> From: Jim.Coomes at seagate.com [mailto:Jim.Coomes at seagate.com]
> Sent: Friday, October 01, 2004 2: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
>=20
>=20
>=20
>=20
>=20
>=20
> This issue of obsoleting FCP_DL and FCP_BIDIRECTIONAL_DL was=20
> raised due to
> a change in processing these fields in FCP-3.
>=20
> The function of the FCP_DL field in FCP and FCP-2 required=20
> 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=20
> RAID vendors have
> implemented the checking and transfer behavior to this=20
> requirement. This
> has lead to many test conditions for compliance to the=20
> required behaviors.
>=20
> Tape vendors find the truncated transfers unacceptable.=20
> Recovery from a
> partial transfer could easily require a repositioning of the tape.
>=20
> In FCP-3, the recommended response ( a "should") to FCP_DL and
> FCP_BIDIRECTIONAL_DL field values that do not match the=20
> expected transfer
> length identified in the CDB is to fail the command with no=20
> transfer and
> check condition.
>=20
> As currently documented in FCP-3, disk drive and RAID vendors=20
> "should" fail
> commands with FCP_DL and FCP_BIDIRECTIONAL_DL field values=20
> considered in
> error.
>=20
> Is failing the command acceptable to current implementation?
>=20
> Jim
>=20
>=20
>=20

To Unsubscribe:
mailto:t11_3-request at mail.t11.org?subject=3Dunsubscribe





More information about the T10 mailing list