RE: SCSI Format/Copy CDB support

["Julian Satran" <Julian_Satran@il.ibm.com>]

That would be a mistake. It may affect commands intended to be dropped.

If the window has moved past CmdSN you DO NOT reissue the command (that is clear in the text).

Julo

"Amir Shalit" <amir@astutenetworks.com> 28-01-02 19:35

To:        Julian Satran/Haifa/IBM@IBMIL         cc:                 Subject:        RE: SCSI Format/Copy CDB support

Julo,

We only need to ADD a single line to section 2.2.2.1 as follows:

"CmdSN must change if the ExpCmdSN/MaxCmdSN window has moved."

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."

Amir

From David Black:

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: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, January 27, 2002 9:17 PM
To: Amir Shalit
Subject: RE: SCSI Format/Copy CDB support


Amir,

A carefull reading of the spec will enable you to see that things are covered.
I do not plan to add text - it only creates new sources of errors.

Julo

"Amir Shalit" <amir@astutenetworks.com> Sent by: owner-ips@ece.cmu.edu 26-01-02 20:14

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
> 
> 
> 
> 
> 
> 
>