Mike Christie wrote:
Hannes Reinecke wrote:
Today, instead of #2, the Red Hat multipath tools guy and I were talking
about doing a probe with SG_IO. For example we would send down a path
tester IO and then wait for it to be failed with DID_TRANSPORT_FAILFAST.
No. this is exactly what you cannot do. SG_IO will be stalled when the
sdev is BLOCKED and will only return a result _after_ the sdev
transitions
_out_ of the BLOCKED state.
Translated to FC this means that whenever dev_loss_tmo is _active_ (!)
no I/O will be send out neither any I/O result will be returned to
userland.
That is not true anymore. When fast io fail fires, the sdev and rport
will be blocked, but the the fc class will call into the LLD to have it
I miswrote that. The rport will be show blocked state, but when fast io
fail tmo fires, fc_terminate_rport_io will unblock the sdev, and the fc
class chkready will fail any IO sent to it and of course
terminate_rport_io will fail IO in the driver like I said below. And
then you do not need a terminate_rport_io callback to have the fast io
fail tmo now. If you set that timer at least IO in the block queue and
new IO will be failed.
fail any IO still running in the driver. The FC class will then fail any
IO in the block queues, and then it will also fail any new IO sent to it.
With your patch to have multipath-tools set fast io fail for multipath,
then we should always get the IO failed before dev_loss_tmo fires.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
