Re: Re-sending a command

[Julian Satran <Julian_Satran@xxxxxxxxxx>]

The effect of ExpCmdSN is the same as
plugging in the holes.
I have a hard time understanding how
an LU reset can be executed in the presence of hole - as the target has
no way knowing if the commands in the "holes" refer to the LU
being reset or to some other LU. So IMHO from the POV of the LU in question
no command preceding the LU reset can be resent - i.e., the effect is like
the holes are plugged for the unit on which an LU reset was sent and the
initiator should not send any after the LU reset.

Julo

"Mallikarjun C." <cb_mallikarjun@xxxxxxxxx>

17/08/06 08:39

To	ips@xxxxxxxx
cc
Subject	Re: Re-sending a command

Sorry, I am catching up late on this thread.

LU reset actually does not by itself plug the holes
since it is not a target-scoped request like warm &
cold resets.  

OTOH, as Ken illustrated in his example, whenever a
TMF Response with an ExpCmdSN larger than the
timed-out command is sent by the target, the timed-out
command is implicitly acknowledged and the left edge
of the CmdSN window has advanced beyond that of
timed-out command.  RFC 3720 is sufficiently explicit
on that point.

Mallikarjun



--- Julian Satran <Julian_Satran@xxxxxxxxxx> wrote:

> Eddy,
> 
> The LU reset "plugs the holes" in command sequence
> and the old CmdSN 
> should not be used (it is definitely an initiator
> bug). If you have seen 
> it Mallikarjun may want to mention that dropping the
> command is the 
> expected behavior of the target after all the task
> management commands 
> that "plug the holes" in the implementation guide.
> 
> Julo
> 
> 
> 
> "Eddy Quicksall"
> <eddy_quicksall_iVivity_iSCSI@xxxxxxxxxxx> 
> 10/08/06 01:34
> 
> To
> <ips@xxxxxxxx>
> cc
> Amit Kumar <Amit_Kumar@xxxxxxxxxxx>
> Subject
>  Re-sending a command
> 
> 
> 
> 
> 
> 
> It was brought to my attention that one initiator
> being tested will 
> re-issue a "timed out" command using the same CmdSN
> after it has issued a 
> LU Reset. When this happens the command is dropped.
> Note that this is on a 
> single connection session.
>  
> I'm wondering if this could be an initiator bug or
> if there is a case 
> where it is actually valid (in the report I have I
> don't know if the 
> initiator also reissued the command with a valid
> CmdSN or not).
>  
> Does anyone know?
>  
> Eddy_______________________________________________
> Ips mailing list
> Ips@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ips
> 
> > _______________________________________________
> Ips mailing list
> Ips@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ips
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips