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

Elliott, Robert (Server Storage) elliott at hp.com
Sun Oct 10 07:53:10 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
*

Including excerpts from various replies on the thread, and dropping the
crosspost to the t11_3 list (which I probably cannot post to, not being
subscribed to it):

> * From the T10 Reflector (t10 at t10.org), posted by:
> * Matthew Jacob <mj at feral.com>
> *
> Jim Coomes wrote:
> > 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?
> 
> From my point of view, yes.
> 
> However, I should note that the Group 1 VERIFY command as 
> implemented in Windows 2003 using the QLogic 23XX HBA and
> the vendor supplied driver does seem to send a command with 
> a CDB payload that does indicate a data 
> transfer should take place but with a DL field value of zero.
> 
> Since this command is a crucial and often required part of 
> the CHKDSK for NTFS, electing to fail the command in one target 
> implementation was not an acceptable option :-).
> 
> -matt

VERIFY only transfers write data when the BYTCHK bit is set to
one.  If FCP_DL prevents the target from receiving any write
data, how is the target interpreting this command?

It doesn't seem prudent to pretend the BYTCHK bit is set to 
zero and return GOOD status only based on whether the target
can read the medium.  The software that asked for BYTCHK isn't 
getting what it requested (comparing the provided write data 
with the data on the medium).

> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Robert Snively" <rsnively at Brocade.COM>
> * 
> Jim Coomes wrote:
>> 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.
> 
> 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".

The proposal for FCP-3 (03-393r1, which has not been
accepted yet) is to add the CHECK CONDITION description
only for the overrun case ("if the command requested
data beyond FCP_DL be transferred..."), not the underrun 
case.

The paragraph being changed is:
9.3.2 FCP_DATA IUs for SCSI read and SCSI write operations
"During any data transfer, the initiator shall have available
a buffer of length FCP_DL. The buffer contains data to be 
transferred to the target if the operation is a write operation 
(i.e., an operation that uses the Data Out action, IU T6). 
The buffer receives the data if the operation is a read operation 
(i.e., an operation that uses the Data In action, IU I3). 
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 FC_RSP IU shall contain the 
FCP_RESID_OVER 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.7)."

The last sentence is the problem, and is the one that is proposed 
to be replaced with:
"The command should return CHECK CONDITION status with a sense key
of ILLEGAL REQUEST and an additional sense code of INVALID FIELD
IN INFORMATION UNIT... Data beyond the FCP_DL count shall not 
be transferred and the appropriate overrun condition shall be 
presented (see 9.4.7)."

> * From the T10 Reflector (t10 at t10.org), posted by:
> * William Studenmund (wrstuden at wasabisystems.com)
> *
> Matthew Jacob wrote:
>> 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 I understand these fields, the correspond directly to
> the Expected Data Transfer Length and Expected Read-Data
> Length fields (the latter only used in a BiDi command) in
> the iSCSI SCSI Command Request PDU. So keeping them around
> would facilitate easy translation between FC and iSCSI.

iSCSI devices actually face the same issue as Fibre Channel
devices about how to handle a SCSI command where the Expected
Data Transfer Length field is too short.  RFC 3720 just lacks 
a sentence saying "the command is completed normally" to prompt
people to notice the problem.  Perhaps SAM-4 needs to own this 
rule so it can be applied to all transport protocols with 
redundant data length fields.

If FCP_DL were obsoleted, a FC to iSCSI bridge sending a 
command to an iSCSI target could just set the Expected Data 
Transfer Length field to FFFFFFFFh; the iSCSI target would 
still be able to return GOOD status, but would always report 
an underrun.

Obsolesence would have to be negotiated in PRLI.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


*
* 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 mailing list