SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI : digest error handling violates EMDP/InDataOrder



    
    
    Santosh,
    
    Let's take a systematic approach to it.
    
    Restriction on data ordering are required if the source or the destination
    of the data is unable to deliver or take data data in any order other that
    sequential.
    
    Semiconductor or other direct access memories don't  have this restriction.
    
    Tapes and other sequential media do have this type of restriction and so
    some streaming devices.
    
    If the restricted device is a target of a SCSI operation with an
    unrestricted initiator then:
    
    a. on reads the target can always ship its data in sequential order
    b. on writes the target can  always request the data in sequential order
    
    However if the restricted device is an initiator then:
    
    a. on reads the initiator will request the target to send the data in order
    b. on writes the restricted initiator will have to get the R2Ts in order
    from the target and will be able to support data recovery through an R2T
    only if it has enough buffered data.
    
    A restricted device will act as an initiator only if it becomes a third
    part copy manager (CM) in a third party operation an does copy from one of
    its devices to another device.
    
    Introducing a new mode bit (as Robert Snively seems to suggest) will not
    change the fact that the restriction can't be upholded
    and do recovery unless the restricted initiator has enough memory.
    
    The spec should only specify a way to terminate a command in those
    conditions and leave it at that.
    
    I will change the wording of the DataOrder to make it clearer but I
    consider the whole issue entirely academic and overblown.
    
    Recall also that a CM implemented which such severe buffering restrictions
    violates the basic SCSI assumption that a target is the data master.
    
    Regards,
    Julo
    
    
    
    Santosh Rao <santoshr@cup.hp.com> on 28/04/2001 00:03:26
    
    Please respond to Santosh Rao <santoshr@cup.hp.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   Black_David@emc.com, ips@ece.cmu.edu
    Subject:  Re: iSCSI : digest error handling violates EMDP/InDataOrder
    
    
    
    
    julian_satran@il.ibm.com wrote:
    >
    > David,
    >
    > I read Bob's mail and my interpretation is similar to his. However I
    think
    > that SPC explicitly states that different transports are free to
    interpret
    > and make use of this page as they find appropriate.
    >
    > I have a hard time understanding Santosh's objection as it does not refer
    > to the reason the EMDP is there but to the way it is written in FCP (not
    > iSCSI).
    
    Julian,
    
    As has been stated earlier, EMDP allows control over the order in which
    the target requests outbound data or sends inbound data. EMDP can be
    used by initiators to control this order and turn off out-of-order R2T
    requests [as well as turn off out of order read data pdus].
    
    This is a useful control option and is already provided by other SCSI
    transports. What good reason exists to deny this provision in iSCSI ?
    
    Also, I have some concerns about the ambiguous definition of DataOrder.
    
    Per the spec :
    "DataOrder=<yes|no>
    
    The default is yes but targets MAY support no. No is used by iSCSI to
    indicate that the data PDUs can be in any order (EMDP = 1). Yes is used
    to indicate that incoming data PDUs have to be at continuously
    increasing addresses (EMDP = 0)."
    
    Based on the above definition wording :
    
    a) How is DataOrder interpreted for WRITE I/Os ?
    b) Is the ordering across the entire SCSI command or a subset of the I/O
    ? If so, what constitutes this subset ?
    
    Different implementors can arrive at different interpretations reading
    the above definition !
    
    - Santosh
     - santoshr.vcf
    
    
    
    


Home

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