If fast_io_fail_tmo isn't set, it will be use the DEFAULT_FAST_IO_FAIL in
select_fast_io_fail.
So, multipath will not run the limited of dev_loss_tmo to 600.
And I think using MP_FAST_IO_FAIL_UNSET as the condition is meaningless after
multipath
run select_fast_io_fail even if it's not set.
原始邮件
发件人：BenjaminMarzinski
收件人：彭亮10137102
抄送人：＜dm-devel@redhat.com＞张凯10072500
日 期 ：2016年11月29日 08:30
主 题 ：Re: [dm-devel] [PATCH] libmultipath: ensure dev_loss_tmo will be update to
MAX_DEV_LOSS_TMO if no_path_retry set to queue
On Fri, Nov 25, 2016 at 02:36:04PM +0800, peng.lia...@zte.com.cn wrote:
＞ From: PengLiang ＜peng.lia...@zte.com.cn＞
＞
＞ If no_path_retry set to queue, we should make sure dev_loss_tmo update to
MAX_DEV_LOSS_TMO.
＞ But, it will be limit to 600 if fast_io_fail_tmo set to off or 0 meanwhile.
Doesn't the system still limit dev_loss_tmo to 600 if fast_io_fail_tmo isn't
set. Multipath
was using this limit, since the underlying system uses it.
-Ben
＞
＞ Signed-off-by: PengLiang ＜peng.lia...@zte.com.cn＞
＞ ---
＞ libmultipath/discovery.c | 3 ++-
＞ 1 file changed, 2 insertions(+), 1 deletion(-)
＞
＞ diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
＞ index aaa915c..05b0842 100644
＞ --- a/libmultipath/discovery.c
＞ +++ b/libmultipath/discovery.c
＞ @@ -608,7 +608,8 @@ sysfs_set_rport_tmo(struct multipath *mpp, struct path
*pp)
＞ goto out
＞ }
＞ }
＞ - } else if (mpp-＞dev_loss ＞ DEFAULT_DEV_LOSS_TMO) {
＞ + } else if (mpp-＞dev_loss ＞ DEFAULT_DEV_LOSS_TMO &&
＞ + mpp-＞no_path_retry != NO_PATH_RETRY_QUEUE) {
＞ condlog(3, "%s: limiting dev_loss_tmo to %d, since "
＞ "fast_io_fail is not set",
＞ rport_id, DEFAULT_DEV_LOSS_TMO)
＞ --
＞ 2.8.1.windows.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
