Re: Target Reset handling

[Ralph Weber <ralphoweber@compuserve.com>]

James Smart wrote:

<snip>

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

} b) Why not require async events to all initiators ?

} The biggest headache with Target Reset is how long it takes for the other
} initiators to recognize the device has been reset. The 1st new i/o will get
} a Unit Attention CA, but this status is typically seen only by the SCSI
} class driver (e.g. disk/tape/etc). Unless instructed by the class driver,
} the port level driver (e.g. scsi/fc/iscsi hba) will have to timeout the
} i/o's (if timing was requested) to recover their context. If the class
} driver does try to tell the port driver, it typically will do so in a crude
} fashion - issuing abort requests on the i/o's it knows about.

Checkout ftp://ftp.t10.org/t10/document.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.

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

Thanks.

Ralph...