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

Dave.Baldwin at Emulex.Com Dave.Baldwin at Emulex.Com
Fri Oct 1 16:13:52 PDT 2004

Hopefully we have enough dissention in the ranks now to say that we =
will not obsolete these fields, which would cause various =
interoperability issues to occur.

So, on to Jim's point on the change in behavior made to FCP-3. I would =
really like to understand why people feel it is necessary to modify the =
current behavior in FCP-2. I don't buy (without more convincing) the =
argument that tape vendors are being hurt by the current requirement, =
and that failing the entire I/O will be better as tape hasn't moved.

I believe what we are talking about here is software sending a bad =
command to a target. If the CDB doesn't match the FCP_DL field, then =
there is a programming error that needs to be fixed. If the tape drive =
fails the entire command, what is the recovery mechanism? It typically =
will fail the backup, maybe after various retries of the same malformed =
command. This would have the same end result using the FCP-2 or FCP-3 =

Yes, the tape driver could get real smart and go read the blocksize =
|from the drive, compute the actual FCP_DL field that matches, and then =
execute the fixed command. However, one could argue that this should =
have been done in the first place, eliminating the need for the =
recovery logic. Recomputing the correct value could cause data =
corruption if it was actually the CDB that was wrong, and the increase =
to FCP_DL now allowed the device to write to memory it should not have =

Do we really need to change this in FCP-3? What problem does this =

Dave Baldwin

-----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

This issue of obsoleting FCP_DL and FCP_BIDIRECTIONAL_DL was raised due =
a change in processing these fields in FCP-3.

The function of the FCP_DL field in FCP and FCP-2 required targets to =
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 =
implemented the checking and transfer behavior to this requirement. =
has lead to many test conditions for compliance to the required =

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 =
length identified in the CDB is to fail the command with no transfer =
check condition.

As currently documented in FCP-3, disk drive and RAID vendors "should" =
commands with FCP_DL and FCP_BIDIRECTIONAL_DL field values considered =

Is failing the command acceptable to current implementation?


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

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

More information about the T10 mailing list