Hi Mike, Mike Christie wrote: > 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. > Indeed, I didn't look closely enough. Ok, so I/O will be failed after terminate_rport_io. So that means we can just implement a new netlink message after terminate_rport_io to inform the multipath daemon about this changes. And, of course, we _really_ should introduce a new sdev state here. Having the sdev set to 'RUNNING' but having all I/O failed in the transport class is just a quirky behaviour which is bound to cause trouble. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- 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
