On 08/01/2016 10:59 AM, Mike Snitzer wrote:
This says to me that must_push_back is returning false because
dm_noflush_suspending() is false. When this happens -EIO will escape up
the IO stack.
And this confirms that must_push_back() calling dm_noflush_suspending()
is quite suspect given queue_if_no_path was configured: we should
_always_ pushback if no paths are available.
I'll dig deeper on really understanding _why_ must_push_back() is coded
like it is.
Hello Mike,
Earlier I had reported that I observe this behavior with
CONFIG_DM_MQ_DEFAULT=y after the first simulated cable pull. I have been
able to reproduce this behavior with CONFIG_DM_MQ_DEFAULT=n but it takes
a large number of iterations to trigger this behavior. The output that
appears on my setup in the kernel log with a bunch of printk()'s added
in the dm-mpath driver for CONFIG_DM_MQ_DEFAULT=n is as follows (mpath
254:0 and /dev/mapper/mpathbe refer to the same multipath device):
[ 314.755582] mpath 254:0: queue_if_no_path 0 -> 1
[ 314.770571] executing DM ioctl DEV_SUSPEND on mpathbe
[ 314.770622] mpath 254:0: queue_if_no_path 1 -> 0
[ 314.770657] __multipath_map(): (a) returning -5
[ 314.770657] map_request(): clone_and_map_rq() returned -5
[ 314.770658] dm_complete_request: error = -5
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
