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

RRose at exabyte.com RRose at exabyte.com
Wed Sep 24 17:35:34 PDT 2003


INCITS T11.3 Mail Reflector
********************************
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_01C382FC.EE8CA4F0
Content-Type: text/plain;
	charset="iso-8859-1"

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_01C382FC.EE8CA4F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset="iso-8859-1"

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

 RE: [T11.3] 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>          sp;          
> = t11_3 at mail.t11.org         =             =             =            
>         ;           ;    
>         ;           ; Sent = by:           sp;     = cc:            = 
>         ;           ;           ;           ;           ;     
>         ;  
>         ;           ; owner-t10 at t10.org        = Subject:  RE: 
> [T11.3] FCP-3 Work Item = #4           p;           p;            = 
>         ;   
>         ;           ;           ;           ;           ;     
>         ;           ;           ;           ;           ;     
>         ;  
>         ;           ;           ;           ;           ;     
>         ;           ;           ;           ;           ;     
>         ;  
>         ;           ; 09/24/2003 = 01:56           nbsp;            = 
>         ;           ;           ;           ;           ;     
>         ;  
>         ;           ; = PM           p;           p;           p;  
>         ;           ;           ;           ;           ;     
>         ;  
>         ;           ;           ;           ;           ;     
>         ;           ;           ;           ;           ;     
>         ;  
>         ;           ;           ;           ;           ;     
>         ;           ;           ;           ;           ;     
>         ;  
> 
> 
> 
> 
> 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 !=3D 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=3Dunsubscribe 
> 
> 
------_=_NextPart_001_01C382FC.EE8CA4F0--




More information about the T10 mailing list