SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: SCSI Format/Copy CDB support



    The CmdSN window should take care of the "long time"
    issue - once the Window (ExpCmdSN/MaxCmdSN) has moved
    past a particular CmdSN, the initiator knows that the
    target successfully received the command, and reissuing
    the command with the same CmdSN would be an error.
    Julian - please add a suitable clarification to the
    next version of the spec.
    
    Thanks,
    --David
    
    > -----Original Message-----
    > From: Amir Shalit [mailto:amir@astutenetworks.com]
    > Sent: Saturday, January 26, 2002 1:15 PM
    > To: Black_David@emc.com
    > Cc: ips@ece.cmu.edu
    > Subject: RE: SCSI Format/Copy CDB support
    > 
    > 
    > David,
    > 
    > I agree. Lets clarify it in the spec. We also must make
    > sure that iSCSI doesn't reissue a command due to connection
    > drop that happened a "long time" after the command was 
    > originally issued.
    > 
    > Amir
    > 
    > -----Original Message-----
    > From: Black_David@emc.com [mailto:Black_David@emc.com]
    > Sent: Saturday, January 26, 2002 12:32 AM
    > To: amir@astutenetworks.com
    > Cc: ips@ece.cmu.edu
    > Subject: RE: SCSI Format/Copy CDB support
    > 
    > 
    > Ah, I see the confusion.  In that section, "reissued"
    > refers to reissuing a command due to holes in the command
    > sequence (e.g., digest failure, connection drop).  In
    > the scenario of interest, the command is not being
    > reissued by iSCSI - SCSI is aborting the old command
    > based on the task tag and issuing a new command which
    > will get a new CmdSN (iSCSI will probably have long since
    > forgotten the CmdSN assigned to the original command).
    > A sentence or two to clarify this wouldn't hurt.
    > 
    > --David
    > 
    > > -----Original Message-----
    > > From: Amir Shalit [mailto:amir@astutenetworks.com]
    > > Sent: Friday, January 25, 2002 7:03 PM
    > > To: Julian Satran
    > > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu
    > > Subject: RE: SCSI Format/Copy CDB support
    > > 
    > > 
    > > Julo,
    > > 
    > > I was talking about initiator aborting the command
    > > ,say two hours after it was sent, and than reissue
    > > the same command with the old CmdSN (according to
    > > the spec).
    > > 
    > > I agree with you that the spec covers all other cases
    > > since once a command is delivered, CmdSN doesn't
    > > matter much and ITT or TTT are used to match the
    > > task.
    > > 
    > > Amir
    > > 
    > > -----Original Message-----
    > > From: owner-ips@ece.cmu.edu 
    > [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > > Julian Satran
    > > Sent: Friday, January 25, 2002 2:14 PM
    > > To: Amir Shalit
    > > Cc: ips@ece. cmu. edu (E-mail); Julian Satran; owner-ips@ece.cmu.edu
    > > Subject: RE: SCSI Format/Copy CDB support
    > > 
    > > 
    > > 
    > > Amir,
    > > CmdSN is completely secondary in abort task.
    > > The main element is the Initiator Task Tag.
    > > If ITT is not found at abort then the target, under some 
    > > cirscumstances,
    > > will look for a hole at CmdSN to fill it or will answer 
    > > negatively the Task
    > > Abort.
    > > 
    > > Julo
    > > 
    > > 
    > > 
    > >                     "Amir Shalit"
    > >                     <amir@astutenet       To:     Julian
    > > Satran/Haifa/IBM@IBMIL
    > >                     works.com>            cc:     "ips@ece. cmu. edu
    > > \(E-mail\)" <ips@ece.cmu.edu>,
    > >                                            <owner-ips@ece.cmu.edu>
    > >                     25-01-02 18:49        Subject:     RE: 
    > > SCSI Format/Copy
    > > CDB support
    > > 
    > > 
    > > 
    > > 
    > > 
    > > 
    > > Julo,
    > > 
    > > I agree with you on (2).
    > > 
    > > Section 2.2.2.1 is saying:
    > > "A numbered iSCSI request will not change its allocated CmdSN
    > > regardless of the number of times and circumstances in which it is
    > > reissued."
    > > 
    > > A long duration SCSI command may be aborted by a task management
    > > command and than reissued by iSCSI with a stale CmdSN.
    > > 
    > > Amir
    > >      -----Original Message-----
    > >      From: owner-ips@ece.cmu.edu 
    > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > >      Julian Satran
    > >      Sent: Friday, January 25, 2002 1:21 AM
    > >      To: Amir Shalit
    > >      Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu
    > >      Subject: Re: SCSI Format/Copy CDB support
    > > 
    > > 
    > >      Amir,
    > > 
    > >      The draft says in several places that CmdSN is not 
    > > important after the
    > >      task gets to SCSI.
    > >      On 2 yes you might be right but that is purely an 
    > implementation
    > >      issue. Format commands do not time-out
    > >      at SCSI level and iSCSI has no cause to e "nervous" - 
    > nothing is
    > >      expected.
    > > 
    > > 
    > >      Julo
    > > 
    > > 
    > > 
    > > 
    > >    "Amir Shalit"
    > >    <amir@astutenetworks.com>              To:        
    > > "ips@ece. cmu. edu
    > >    Sent by: owner-ips@ece.cmu.edu \(E-mail\)" <ips@ece.cmu.edu>
    > >                                           cc:
    > >                                           Subject:        
    > > SCSI Format/Copy
    > >    25-01-02 02:10                 CDB support
    > > 
    > > 
    > > 
    > > 
    > > 
    > > 
    > > 
    > >      I see a few problems in implementing the format/copy 
    > > commands over
    > >      iSCSI
    > > 
    > >      1) CmdSN may wrap between command and response 
    > (assuming multiple
    > >      LUNs)
    > > 
    > >      2) iSCSI keepalive NOPs may be required to keep the 
    > > connection open
    > >      during format
    > > 
    > > 
    > > 
    > > 
    > > 
    > > 
    > > 
    > 
    > 
    > 
    


Home

Last updated: Mon Jan 28 14:17:53 2002
8518 messages in chronological order