SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: underrun with a check condition



    On Mon, 17 Feb 2003, Eddy Quicksall wrote:
    
    > At the initiator, it would be up to the transport driver whether or not to
    > pass these fields to the ULP depending on the status value.
    > 
    > At the target, the SCSI layer should not be knowledgeable of the expected
    > transfer length because with parallel SCSI that is not passed on the wire.
    > So the setting of these fields should be up to the transport driver.
    
    You ask for X you had better get X.
    If you do not get X, but X - N, the initiator (general terms now) is
    expected to ignore the results and retry.  If the retry fails then the
    target (general terms now) is expected to issue a failed media status.
    Now how all these relate to what iSCSI sends or recieves is up the the
    implimentation.
    
    The SCSI does know the length if it a data in/out phase.
    The attached CDB describes this fully.
    
    Are you stating a position of the response?
    
    > The only thing we need to know in iSCSI is the intent of paragraph 10.4.1.
    
    Gurr, now I have to go re-read to finish the second half of the reply.
    
    
    Cheers,
    
    --andre
    
    > Since that paragraph does not specify which status's it applies to, it is
    > assumed that it applies to ALL statuses. I just wanted to be sure that was
    > then intent. My examples were just to stir up some thinking on the issue.
    > 
    > Eddy
    > 
    > -----Original Message-----
    > From: Julian Satran [mailto:satran@haifasphere.co.il] 
    > Sent: Monday, February 17, 2003 7:36 AM
    > To: 'Andre Hedrick'
    > Cc: 'Santosh Rao'; 'Eddy Quicksall'; '"Ips@Ece.Cmu.Edu"'
    > Subject: RE: iSCSI: underrun with a check condition
    > 
    > The whole discussion is at the border between SCSI and iSCSI.
    > All I said is not that iSCSI will not process the command but rather
    > that SCSI LLP will
    > Know that it does not have to do anything (almost - it has to look if
    > the command is a sense or an inq) but send the status. iSCSI will act as
    > usual. My assumption was that the flags and residual length are
    > generated by SCSI as it is the one relating byte counts with CDB
    > information/device information
    > 
    > Regards,
    > Julo
    > 
    > 
    > -----Original Message-----
    > From: Andre Hedrick [mailto:andre@linux-ide.org] 
    > Sent: 17 February, 2003 14:11
    > To: Julian Satran
    > Cc: 'Santosh Rao'; 'Eddy Quicksall'; '"Ips@Ece.Cmu.Edu"'
    > Subject: RE: iSCSI: underrun with a check condition
    > 
    > 
    > 
    > Julian,
    > 
    > This implies the Status Sequence Number and the Expected Command
    > Sequence Window shall not be adjust by the target, period.  Thus the
    > initiator would timeout and fail the command, or follow through on
    > appropriate ERL states until it decays to a logout-login.
    > 
    > So I agree the target does not care about U/O bits for the most part in
    > this case, but acknowledging the command regardless of direction will
    > corrupt data to platter (for future expected reads) or generate a
    > dereferrence null pointer from the filesystem or requesting application.
    > 
    > This assumes the command was a data in or out phase.
    > If it was a task management command, I suspect things would become fuzzy
    > for error faults from the requesting application.
    > 
    > Other than the HBA and/or Spindle to fault, why would one expect the
    > target to no process the command?  Obviously one could have a net/fabric
    > transport problem and miss the command, but there are other rules to
    > protect both sides unless the target supports out of order command.
    > 
    > Regardless which end of the transaction on target one picks, a failure
    > to process will jam the command and status sequence numbers some how.
    > 
    > The only other issue addressed by Eddy is the case of partial
    > completions of the request.  Nowhere in the drafts or now RFC does it
    > permitt such events without the U_bit being set.  Any target that
    > permits an overrun based on the allocated data lenght requested is sure
    > to explode, if it does not then the initiator will have a problem with
    > the F_bit missing. Unless the target sets the F_bit proper in the
    > stream.  One then encounters the problem of dumping the remainder if the
    > O_bit is not set with the (effectively early F_bit).
    > 
    > If I have rambled and failed to describe the points clearly, please let
    > me know.
    > 
    > Cheer,
    > 
    > Andre Hedrick
    > LAD Storage Consulting Group
    > PyX Technologies, Inc.
    > 
    > On Mon, 17 Feb 2003, Julian Satran wrote:
    > 
    > > Santosh,
    > > 
    > > For any check condition in which the target did process the command 
    > > this is the expected behavior. The example Eddy gave involves a target
    > 
    > > that due to ACA or BUSY does not initiate processing the command.
    > > In this case the target provider does not HAVE TO set the U/O bits
    > (and
    > > the associated values).
    > > The relevant piece of information appears in SAM2 5.3.2 that indicates
    > > that status precedence.
    > > Obviously a target MAY set the U/O bits although  I doubt that an
    > > initiator will look them up.
    > > 
    > > Regards,
    > > Julo
    > > 
    > > 
    > > -----Original Message-----
    > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf 
    > > Of Santosh Rao
    > > Sent: 16 February, 2003 23:28
    > > To: Eddy Quicksall
    > > Cc: "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)"
    > > Subject: Re: iSCSI: underrun with a check condition
    > > 
    > > 
    > > Eddy,
    > > 
    > > Yes, anytime the amount of data transferred does not match the data 
    > > transfer length specified, the target must set the U bit or O bit, 
    > > depending on whether an underflow or overflow occurred.
    > > 
    > > A recovered error check condition may be returned as the response to a
    > 
    > > scsi command which was processed to completion. The recovered error 
    > > indicates that a previous command completed successfully with some 
    > > recovery action by the device server and the sense data provides 
    > > additional details on that previous command.
    > > 
    > > The current command on which a recovered error check condition was 
    > > returned may have been processed to completion, or experienced some 
    > > underflow or overflow. This information must be conveyed by the target
    > 
    > > in the iscsi scsi response pdu using the appropriate fields to 
    > > describe the underflow or overflow.
    > > 
    > > Thanks,
    > > Santosh
    > > 
    > > 
    > > > Should the target set the U bit when it gives a check condition to a
    > > > data-in command?
    > > >  
    > > >  
    > > > Eddy
    > > 
    > 
    
    Andre Hedrick
    LAD Storage Consulting Group
    
    


Home

Last updated: Mon Feb 17 17:19:09 2003
12327 messages in chronological order