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