Re: Target Reset handling

[Stephen Bailey <steph@cs.uchicago.edu>]

> The problem is that at this reset is at a really high level (the
> iSCSI/TCP/IP stack must be working in the first place to even
> receive and process the command).

Agreed.

> If iSCSI/TCP/IP is in a state that it can receive and decode the
> "big hammer" reset iSCSI PDU, I don't think it would be in a state
> that it needs to be reset.

I don't agree with this.  I've seen plenty of failure scenarios with
FCP targets where they were swallowing packets, but still in the
weeds.  The FCP target reset task management function cured them in
this case.  I can't say that what percentage of the total failure
modes were in this category.  There were certainly also many where the
directed LIP (or even power cycle!) was the only way out.

The initiator should be allowed to hit anything within reach of a
hammer to provide the maximum set of recovery/work-around options.
Providing this capability will encourage target vendors to make the
hammer work as robustly and forcefully as possible, to avoid the
unpleasant alternative of having to follow their products into the
field on short notice to fix them while THE CUSTOMER IS WATCHING.

Steph