Re: Re-sending a command

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." <[email protected]> 
17/08/06 08:39

To
[email protected]
cc

Subject
Re: [Ips] 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 <[email protected]> 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"
> <[email protected]> 
> 10/08/06 01:34
> 
> To
> <[email protected]>
> cc
> Amit Kumar <[email protected]>
> Subject
> [Ips] 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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> > _______________________________________________
> Ips mailing list
> [email protected]
> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips