SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Data in SCSI Response or SCSI Data



    
    Doug,
    
    It is true that CHECK CONDITION is not presented for transfers
    shorter than the allocation when the SILI bit is set on tape
    drives.  However, for all other cases, it is.
    
    In any case, FCP provides an independent under-run/over-run
    condition that provides the necessary information to 
    "use other methods" that identify shorter or longer than
    expected transfers.  These were provided because the Fibre
    Channel transport mechanism is potentially independent from
    the SCSI command set operations.
    
    Basically, it is always there when the application program
    desires to use it.  Normally, variable length parameter fields
    such as INQUIRY data fields, are self-defining in length.  You
    merely set out a large allocation space and then parse the
    resulting data object to find out where it ends and if it 
    was truncated in an undesirable way.
    
    These are interesting items to keep in mind, and are one of the
    reasons we recommend the FCP_RSP format for the actual response.
    
    Bob
    
    
    
    
    >  -----Original Message-----
    >  From: Douglas Otis [mailto:dotis@sanlight.net]
    >  Sent: Monday, September 11, 2000 11:45 AM
    >  To: Robert Reynolds; 'Stephen Bailey'; ips@ece.cmu.edu
    >  Subject: RE: Data in SCSI Response or SCSI Data
    >  
    >  
    >  Bob,
    >  
    >  SAM-2
    >  "As specified in clause 5, the application client may 
    >  request autosense
    >  service for any SCSI command. If supported
    >  by the protocol and logical unit and requested by the 
    >  application client,
    >  the device server shall only return sense
    >  data in this manner coincident with the completion of a 
    >  command with a
    >  status of CHECK CONDITION."
    >  
    >  SSC
    >  "If the suppress incorrect length indicator (SILI) bit is 
    >  one and the FIXED
    >  bit is zero, the device server shall:
    >  a) Report CHECK CONDITION status for an incorrect length 
    >  condition only if
    >  the overlength condition
    >  exists and the BLOCK LENGTH field in the mode parameter 
    >  block descriptor is
    >  nonzero (see SPC-2); or
    >  b) not report CHECK CONDITION status if the only error is 
    >  the underlength
    >  condition, or if the only error
    >  is the overlength condition and the BLOCK LENGTH field of the mode
    >  parameters block descriptor is zero.
    >  
    >  NOTE 9 Since the residue information normally provided in 
    >  the INFORMATION
    >  field of the sense data may not
    >  be available when the SILI bit is set, other methods for 
    >  determining the
    >  actual block length should be used
    >  (e.g. including length information in the data block).
    >  
    >  If the SILI bit is one and the FIXED bit is one, the device 
    >  server shall
    >  terminate the command with CHECK
    >  CONDITION status and the sense key shall be set to ILLEGAL 
    >  REQUEST with an
    >  additional sense code
    >  and an additional sense code qualifier of INVALID FIELD IN CDB.
    >  
    >  If the SILI bit is zero and an incorrect length block is read, CHECK
    >  CONDITION status shall be returned
    >  and the ILI and VALID bits shall be set to one in the sense 
    >  data with an
    >  additional sense code and an
    >  additional sense code qualifier of NO ADDITIONAL SENSE 
    >  INFORMATION. Upon
    >  termination, the
    >  logical position shall be after the incorrect length block 
    >  (end-of-partition
    >  side). If the FIXED bit is one, the
    >  INFORMATION field shall be set to the requested transfer 
    >  length minus the
    >  actual number of blocks read
    >  (not including the incorrect length block). If the FIXED bit 
    >  is zero, the
    >  INFORMATION field shall be set to the
    >  requested transfer length minus the actual block length. 
    >  Logical units that
    >  do not support negative values
    >  shall set the INFORMATION field to zero if the overlength 
    >  condition exists."
    >  
    >  From these definitions, do not expect any defined 
    >  information regarding
    >  residue without a Check Condition.  The residue of iSCSI 
    >  within the Read PDU
    >  0x45 is not SCSI related nor does it represent the 
    >  underlength condition you
    >  suggest.  Such underlength data is normally lost and 
    >  uninteresting if the
    >  SILI bit is set.
    >  
    >  Doug
    >  
    >  > -----Original Message-----
    >  > From: owner-ips@ece.cmu.edu 
    [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > Robert Reynolds
    > Sent: Monday, September 11, 2000 8:07 AM
    > To: 'Stephen Bailey'; ips@ece.cmu.edu
    > Subject: RE: Data in SCSI Response or SCSI Data
    >
    >
    > > -----Original Message-----
    > > From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
    > > Sent: Wednesday, September 06, 2000 5:45 PM
    > > To: ips@ece.cmu.edu
    > > Subject: Re: Data in SCSI Response or SCSI Data
    > >
    > >
    > > > When do you get GOOD status and residual counts on a read?
    > > What is causing
    > > > the target to get the length wrong?
    > >
    > > One example is an INQUIRY command.  The inquiry data length is
    > > target-specific.  Typically the CDB allocation length (and DL) are set
    > > to some arbitrary large value (0xff), and the target sends back
    > > everything it has.  The transfer ends with success status.
    > >
    > > There can certainly be transfer residual and no SCSI error status.
    >
    >
    >   Another example is on variable block tape reads.  The Initiator
    >   uses an arbitrary size to read the block and the target sends all
    >   the data in that block.  In many cases the amount of data returned
    >   is less than the amount of data asked for but it is still a GOOD
    >   status.
    >
    >     Bob
    >
    
    


Home

Last updated: Tue Sep 04 01:07:18 2001
6315 messages in chronological order