[T11.3] Re[3]: FCP-3 Work Item #4

RRose at exabyte.com RRose at exabyte.com
Wed Oct 1 13:19:36 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* RRose at exabyte.com
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C38859.55A85D30
Content-Type: text/plain;
	charset="iso-8859-1"

The main issue is to avoid starting the data transfer, since the
stopping in the middle of data transfer on a serial device is
problematic.  As long as the data transfer isn't permitted to start, the
remaining problems are solvable.
 
I don't see any great problems with returning a SCSI Check Condition,
but I might argue for some form of Aborted Command sense key instead of
Illegal Request.  Illegal Request's definition looks pretty specific to
CDB's, Parameter Lists, LUN selection and other upper layer issues.
 
Perhaps Aborted Command/Insufficient Resources would get people looking
at the correct layer and still work with apps which neglect to check the
service delivery information.  This ASC/ASCQ is independent of the data
direction and valid for all devices except OSD, ADC and RBC.  I suppose
you could go with Illegal Request/Insufficient Resources, but that Sense
Key/ASC/ASCQ combination becomes ambiguous with the definition of their
use in Change Aliases and Access Control Out commands. (i.e.
Insufficient buffer for the Parameter List would produce the same result
as exceeding target resources for processing the alias changes.)
 
>From the SAM documents, the data buffers supplied to the Execute Command
remote procedure are required to be enough; however, I haven't found any
definite statement of how to react when this rule is broken.  The
appropriate response might be "Service Delivery or Target Failure" from
the Execute Command remote procedure.  This response is supposed to be
specified in each SCSI Protocol Standard;  unfortunately, I'm also
having trouble finding much reference to this response in the protocol
mappings I've looked at.
 
If we're adding a new ASCQ for Jim's solution, maybe we should just add
something to specifically target things that aren't permitted on the
Execute Command RPC.  (Maybe this already exists, and I've simply not
found it?)
 
Any thoughts,
 
-roger
 
 -----Original Message-----
From: Jim Jones (Engineering) [mailto:Jim.Jones at quantum.com]
Sent: Tuesday, September 30, 2003 7:56 AM
To: 'RRose at exabyte.com'; Paul.A.Suhler at certance.com; t10 at t10.org;
t11_3 at mail.t11.org
Subject: RE: [T11.3] Re: FCP-3 Work Item #4



Roger,
 
I agree with your assessment of the problem and I think rejecting the
FCP_CMND frame with "FCP_CMND Fields Invalid"  would work.  
 
Another option is to report this at the application layer as a SCSI
check condition (sense key 05 - illegal request) and not transfer any
data.  There is an ASC/ASCQ 4B02 for too much write data (SPC-3), we
would need to add one for too much read data or make the current one
more generic - "too much data".
 
My reasoning is as follows:
I've seen a mismatch with the FCP_DL and the CDB transfer length with
test applications that supplied an incorrect length at the ASPI or
SCSIPassthru layer (this length is used as the FCP_DL).  Unfortunately,
these applications are also only looking at the SCSI status byte - this
is 0x00 when "FCP_CMND Fields Invalid" is reported.   Reporting a check
condition may make it more obvious to the "poorly written application"
what is wrong.
 
Jim
__________________________ 
Jim Jones 
Quantum Corporation 
4001 Discovery Dr., Suite 2100 
Boulder, CO 80303 
Jim.Jones at quantum.com 
720-406-5611 
  
 

-----Original Message-----
From: RRose at exabyte.com [mailto:RRose at exabyte.com]
Sent: Wednesday, September 24, 2003 6:36 PM
To: Paul.A.Suhler at certance.com; t10 at t10.org; t11_3 at mail.t11.org
Subject: [T11.3] Re: FCP-3 Work Item #4



Paul, 

I'd suggest the solution of treating this as a transport-layer failure.
This solution already exists on shipping devices from various vendors.
In reality, the error is an issue of bad information or inadequate
resources being provided to the transport-layer by either the
application or an upper-level driver.

It is not practical (or even possible over time) for the host
transport/HBA driver to know the length of the data from parsing the
command.  Addition of new commands and vendor-specific commands simply
prohibit this from a long-term solution.  (Less of a problem with ADT
due to a smaller and presumably better-behaved audience.)

The appropriate point to detect this error is in the target as the cdb
is decoded.  The target is the only point where the cdb can be properly
decoded to determine the amount of data.

If the decoded cdb *potentially* requires more space than has been
specified in FCP_DL, then reject it immediately with "FCP_CMND Fields
Invalid" and don't move any data.  Nobody has any right to expect such a
malformed request to function, because the request must inherently fail
for lack of buffer space; unless, it fails for some other condition
during the execution.

It is absolutely critical that the end-of-buffer be enforced.  Failure
to do so exposes the potential for writing unintended (and possibly
interesting) data to the media.  On reads from the device, an overrun
will overwrite data in the host and corrupt the system.

-roger rose 
 rrose at exabyte.com 


> -----Original Message----- 
> From: Paul.A.Suhler at certance.com [ mailto:Paul.A.Suhler at certance.com
 ] 
> Sent: Wednesday, September 24, 2003 5:06 PM 
> To: t10 at t10.org; t11_3 at mail.t11.org 
> Subject: [T11.3] FCP-3 Work Item #4 
> 
> 
> 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? 
> 
> Thanks, 
> 
> Paul Suhler 
> Certance 
> 
> 
> 
>                                                               
>                                                               
>            
>                       Robert Snively                          
>                                                               
>            
>                       <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                                    
>             
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
>                       09/24/2003 01:56                        
>                                                               
>            
>                       PM                                      
>                                                               
>            
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
> 
> 
> 
> 
> Paul, 
> 
> 
> 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 
> program development. 
> 
> 
> 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. 
> 
> 
> Bob 
> 
> 
> 
> 
> 
> 
> > -----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 
> > 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.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. 
> 
> 
> 
> 
> To Unsubscribe: 
> mailto:t11_3-request at mail.t11.org?subject=unsubscribe
<mailto:t11_3-request at mail.t11.org?subject=unsubscribe>  
> 
> 


------_=_NextPart_001_01C38859.55A85D30
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

 RE: [T11.3] FCP-3 Work Item #4 The main issue is to avoid starting the data transfer, since the stopping in the middle of data transfer on a serial device is problematic.  As long as the data transfer isn't permitted to start, the remaining problems are solvable.
  
 I don't see any great problems with returning a SCSI Check Condition, but I might argue for some form of Aborted Command sense key instead of Illegal Request.  Illegal Request's definition looks pretty specific to CDB's, Parameter Lists, LUN selection and other upper layer issues.
  
 Perhaps Aborted Command/Insufficient Resources would get people looking at the correct layer and still work with apps which neglect to check the service delivery information.  This ASC/ASCQ is independent of the data direction and valid for all devices except OSD, ADC and RBC.  I suppose you could go with Illegal Request/Insufficient Resources, but that Sense Key/ASC/ASCQ combination becomes ambiguous with the definition of their use in Change Aliases and Access Control Out commands. (i.e. Insufficient buffer for the Parameter List would produce the same result as exceeding target resources for processing the alias changes.)
  
 From the SAM documents, the data buffers supplied to the Execute Command remote procedure are required to be enough; however, I haven't found any definite statement of how to react when this rule is broken.  The appropriate response might be "Service Delivery or Target Failure" from the Execute Command remote procedure.  This response is supposed to be specified in each SCSI Protocol Standard;  unfortunately, I'm also having trouble finding much reference to this response in the protocol mappings I've looked at.
  
 If we're adding a new ASCQ for Jim's solution, maybe we should just add something to specifically target things that aren't permitted on the Execute Command RPC.  (Maybe this already exists, and I've simply not found it?)
  
 Any thoughts,
  
 -roger
  
  -----Original Message-----
From: Jim Jones (Engineering) [mailto:Jim.Jones at quantum.com]
Sent: Tuesday, September 30, 2003 7:56 AM
To: 'RRose at exabyte.com'; Paul.A.Suhler at certance.com; t10 at t10.org; t11_3 at mail.t11.org
Subject: RE: [T11.3] Re: FCP-3 Work Item #4


 Roger,
  
 I agree with your assessment of the problem and I think rejecting the FCP_CMND frame with "FCP_CMND Fields Invalid"  would work.  
 
 Another option is to report this at the application layer as a SCSI check condition (sense key 05 - illegal request) and not transfer any data.  There is an ASC/ASCQ 4B02 for too much write data (SPC-3), we would need to add one for too much read data or make the current one more generic - "too much data".
  
 My reasoning is as follows:
 I've seen a mismatch with the FCP_DL and the CDB transfer length with test applications that supplied an incorrect length at the ASPI or SCSIPassthru layer (this length is used as the FCP_DL).  Unfortunately, these applications are also only looking at the SCSI status byte - this is 0x00 when "FCP_CMND Fields Invalid" is reported.   Reporting a check condition may make it more obvious to the "poorly written application" what is wrong.
  
 Jim
 __________________________ 
Jim Jones 
Quantum Corporation 
4001 Discovery Dr., Suite 2100 
Boulder, CO 80303 
Jim.Jones at quantum.com 
720-406-5611 
  
 
 -----Original Message-----
From: RRose at exabyte.com [mailto:RRose at exabyte.com]
Sent: Wednesday, September 24, 2003 6:36 PM
To: Paul.A.Suhler at certance.com; t10 at t10.org; t11_3 at mail.t11.org
Subject: [T11.3] Re: FCP-3 Work Item #4


 Paul, I'd suggest the solution of treating this as a transport-layer failure.  This solution already exists on shipping devices from various vendors.  In reality, the error is an issue of bad information or inadequate resources being provided to the transport-layer by either the application or an upper-level driver. It is not practical (or even possible over time) for the host transport/HBA driver to know the length of the data from parsing the command.  Addition of new commands and vendor-specific commands simply prohibit this from a long-term solution.  (Less of a problem with ADT due to a smaller and presumably better-behaved audience.) The appropriate point to detect this error is in the target as the cdb is decoded.  The target is the only point where the cdb can be properly decoded to determine the amount of data. If the decoded cdb *potentially* requires more space than has been specified in FCP_DL, then reject it immediately with "FCP_CMND Fields Invalid" and don't move any data.  Nobody has any right to expect such a malformed request to function, because the request must inherently fail for lack of buffer space; unless, it fails for some other condition during the execution. It is absolutely critical that the end-of-buffer be enforced.  Failure to do so exposes the potential for writing unintended (and possibly interesting) data to the media.  On reads from the device, an overrun will overwrite data in the host and corrupt the system. -roger rose 
 rrose at exabyte.com 
> -----Original Message----- 
> From: Paul.A.Suhler at certance.com [mailto:Paul.A.Suhler at certance.com] 
> Sent: Wednesday, September 24, 2003 5:06 PM 
> To: t10 at t10.org; t11_3 at mail.t11.org 
> Subject: [T11.3] FCP-3 Work Item #4 
> 
> 
> 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? 
> 
> Thanks, 
> 
> Paul Suhler 
> Certance 
> 
> 
> 
>                                                               
>                                                               
>            
>                       Robert Snively                          
>                                                               
>            
>                       <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                                    
>             
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
>                       09/24/2003 01:56                        
>                                                               
>            
>                       PM                                      
>                                                               
>            
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
> 
> 
> 
> 
> Paul, 
> 
> 
> 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 
> program development. 
> 
> 
> 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. 
> 
> 
> Bob 
> 
> 
> 
> 
> 
> 
> > -----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 
> > 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.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. 
> 
> 
> 
> 
> To Unsubscribe: 
> mailto:t11_3-request at mail.t11.org?subject=unsubscribe 
> 
> 

------_=_NextPart_001_01C38859.55A85D30--




More information about the T10 mailing list