Re: Re-sending a command

Julian, you're right that LU reset cannot be executed
in the presence of holes, and that's consistent with
what I was pointing out.  I was clarifying that an LU
reset automatically does not plug holes as either
flavor of target reset does (the target must wait for
all commands to arrive with LU reset).  So I guess we
are saying the same thing.

Mallikarjun

--- Julian Satran <[email protected]> wrote:

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



__________________________________________________
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