RE: Target Reset handling

["James Smart" <jssmart@nhinternet.com>]

Ralph,

Either I grossly missed led you, or you misread me...


> } Given connections with lots of outstanding traffic, I'd see
> this as a more
> } graceful reset procedure. It allows any outstanding i/o that may be
> } completing while the TR is in transit (or queued for processing on the
> } target) to do so, possibly lightening the load of i/o that has
> to error to
> } complete. This would potentially quicken the recovery time post reset. I
> } would expect this to be more important as the "network" gets larger and
> } longer.
>
> } Note: FCP does support this behavior.
>
> The concept of a target queuing I/O for processing across a target reset
> boggles my mind.  I'm having a really hard time believing that FCP goes
> that far.

I wasn't describing commands being queued across a reset - but rather, the
additional (very small) time on the target side when it may have
received the task mgmt command packet, but hasn't processed it yet (it's
behind other commands received previously, or waiting for a deferred
processing thread to deal with it). Basically more queuing/transmit time
during which other i/o can be completing before the reset takes effect.

My comment on FCP was that it allows the target to ack (send a response) to
the Target Reset - also useful if it does not support the target reset task
management function.


> Checkout ftp://ftp.t10.org/t10/documaent.00/00-229r1.pdf.  It's a proposal
> in progress and has not been approved yet.  But, the issue raised above
> is not limited to iSCSI.

Agreed. I really like the proposal. However, it's yet another optional item
enabled by mode page. Allowing the iscsi target to respond the target reset
function allows some additional flexibility.


> <snip>
>
> } d) Given the history of long error recovery times in multi-initiator
> } environments in both parallel scsi and fibre channel on BDR's/Target
> } Reset's, any speed up in this area would be advantageous.
>
> The real problem is using Target Resets for purposes other than clearing
> an obviously stuck target.  T10 keeps trying to provided the right tools
> for the right uses (e.g., Persistent Reservations) but at least one major
> software vendor sees them as inconveniences instead of assistants.

Agreed.

Emulation of that old parallel scsi BDR via Target Reset and the other
implications on reservations, etc has made it difficult for the OS drivers
to leave it behind.

-- James