[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] LSF: Multipathing and path checking question

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 vger kernel org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]