SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: StatSN and overlapped commands



    Deva,
    
    I think Eddy, you and I are all agreeing. A target MAY detect this error. It isn't required to detect. A Reason code for Reject exists that is appropriate for cases where the target detects the error. We should neither prohibit nor require detection.
    
    And yes, Eddy, I did mean 10.17.1.
    
    Pat
    
    -----Original Message-----
    From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com]
    Sent: Thursday, August 07, 2003 5:07 PM
    To: 'Eddy Quicksall'; pat_thaler@agilent.com
    Cc: ips@ece.cmu.edu
    Subject: RE: StatSN and overlapped commands
    
    
    Since it is implementation specific, a target MAY take care of this scenario
    by a suitable error response as defined in 
    the current spec. If a target implementation can perform this, why prevent
    it?  
    
    Thanks
    
    Deva
    
    
    -----Original Message-----
    From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] 
    Sent: Thursday, August 07, 2003 4:50 PM
    To: pat_thaler@agilent.com
    Cc: ips@ece.cmu.edu
    Subject: RE: StatSN and overlapped commands
    
    
    I assume you mean 10.17.1. Yes, the target could give that response but it
    should not be required to check the ITT. That is what I meant by "make it an
    error". It could take time to do that and the target should not be in the
    business of debugging the initiator.
    
    That is what I meant by "make it an error".
    
    I object to the target (or initiator) being required to do anything to cover
    cases where the other side screwed up ... unless it could adversely effect
    the target (or initiator) such as a crash. 
    
    Eddy
    
    -----Original Message-----
    From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] 
    Sent: Thursday, August 07, 2003 6:54 PM
    To: wrstuden@wasabisystems.com; eddy_quicksall@ivivity.com
    Cc: pat_thaler@agilent.com; satran@haifasphere.co.il; julian@cs.haifa.ac.il;
    Black_David@emc.com; dcuddihy@attotech.com; ips@ece.cmu.edu
    Subject: RE: StatSN and overlapped commands
    
    Eddy,
    
    I'm not sure what you mean by "make it an error". iSCSI already has an error
    that covers this situation doesn't it? I'm looking at 10.7.1 on reason code
    0x09. Note 2 says this includes invalid TTT/ITT.
    
    Pat
    
    -----Original Message-----
    From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]
    Sent: Wednesday, August 06, 2003 1:20 PM
    To: Eddy Quicksall
    Cc: pat_thaler@agilent.com; satran@haifasphere.co.il; julian@cs.haifa.ac.il;
    Black_David@emc.com; dcuddihy@attotech.com; ips@ece.cmu.edu
    Subject: RE: StatSN and overlapped commands
    
    
    On Wed, 6 Aug 2003, Eddy Quicksall wrote:
    
    > I don't think we should make it an error if that implies that the 
    > target needs to check for the error.
    
    In my most recent note, I'm suggesting we make it an error, but that we let
    the target ignore the "error" if it has already terminated the task.
    
    If we don't make it an error, we run into the question of what should a
    target do if the first (status-unacknowledged) task needs to support
    recovery actions. If the second, same ITT, task is allowed to exist, Data
    SNACKs become ambiguous. That strikes me as VERY much against the intent of
    data recovery. :-) Just letting the target report this as an error seems the
    easiest thing to do.
    
    The reason for letting the target ignore this case is so that we permit
    implementations like Pat was describing. If you know you aren't going to do
    any recovery (either you aren't supporting it or it's a SCSI write command
    and thus the target knows all is done), then it's fine to kill the task, and
    then this case isn't ambiguous.
    
    > It seems that if the initiator does this, he probably has a bug or a 
    > race condition that will lead to a bug later. So isn't it his 
    > responsibility to debug his program?
    
    I agree it's the initiator's problem. The thing is that if we don't make it
    an "error", then the target has to deal with the problem, and the corner
    cases can get messy.
    
    So to be clear, I'm suggesting the "it's an error you can ignore if it isn't
    a problem" approach so that we give different target implementations the
    room to deal with the situation as they see fit.
    
    Take care,
    
    Bill
    


Home

Last updated: Thu Aug 07 21:19:32 2003
12798 messages in chronological order