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



    I don't think we should make it an error if that implies that the target
    needs to check for the error.
    
    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?
    
    Eddy
    
    -----Original Message-----
    From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] 
    Sent: Wednesday, August 06, 2003 3:12 PM
    To: pat_thaler@agilent.com
    Cc: 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 pat_thaler@agilent.com wrote:
    
    > Julian,
    >
    > For recovery, the target has to remember the status, but that doesn't
    > mean it has to keep the task information around. It would have the
    > status message linked to StatSN but it would be typical to clear away
    > any task context when that message is generated. Remember that when
    > things are very busy it might get a single acknowledgement that
    > acknowledges multiple status messages from multiple tasks. It isn't
    > efficient to have to go back to do the task context clean up when the
    > status ack comes.
    >
    > It is the initiator's job to not shoot itself in the foot by issuing a
    > new command with the same task tag as one that it hasn't gotten status
    > on yet. For the target, once the status is generated, the task is gone.
    > The status message may still be there available for a resend, but the
    > task is gone. I don't see any requirement in iSCSI or SCSI to do
    > anything other than that.
    
    Pat,
    
    Would this be agreable: we make it an error for the initiator to re-use a
    task tag for which it hasn't received status, and we let the target
    terminate the iSCSI task after sending the status if it is not going to do
    any recovery. Likewise, we permit the target to choose to not terminate
    the iSCSI task until it receives status.
    
    That way you're fine if you shut the task down after sending status, but
    likewise targets that _don't_ shut the task down until receiving status
    are perfectly ok to complain if they notice the task re-use. And I'd
    expect regression testing targets to keep the task around until status ack
    to catch this error case.
    
    While I agree the spec is unclear, I read it and took away the idea that
    the ITT can't be re-used until status is ack'd. :-)
    
    Please note I'm talking about the iSCSI task in all of the above. I agree
    with David that the SCSI task is over before/when we send status. ;-)
    
    Take care,
    
    Bill
    


Home

Last updated: Wed Aug 06 17:19:22 2003
12783 messages in chronological order