[dm-devel] [PATCH] multipathd: fail path when path check timeout

[Christophe Varoqui]

Merged.
Thanks.

On Tue, Oct 11, 2016 at 8:50 AM, <tang.junhui at zte.com.cn> wrote:

> Please have a review for this patch, any comment will be highly
> appreciated.
>
>
>
>
> 发件人:         tang.junhui at zte.com.cn
> 收件人:         christophe varoqui <christophe.varoqui at free.fr>,
> 抄送:        dm-devel at redhat.com, zhang.kai16 at zte.com.cn, "tang.junhui" <
> tang.junhui at zte.com.cn>
> 日期:         2016/08/10 16:11
> 主题:        [PATCH] multipathd: fail path when path check timeout
> ------------------------------
>
>
>
> From: "tang.junhui" <tang.junhui at zte.com.cn>
>
> path should be failed when path status is PATH_TIMEOUT after check,
> otherwise, the valid number of paths in the map would be increased when
> the path status is PATH_UP after the next turn check, which would cause
> the valid number of paths exceeding the total number of paths in the map.
>
> Signed-off-by: tang.junhui <tang.junhui at zte.com.cn>
> ---
> multipathd/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/multipathd/main.c b/multipathd/main.c
> index f5e9a01..01f1e58 100644
> --- a/multipathd/main.c
> +++ b/multipathd/main.c
> @@ -1585,7 +1585,7 @@ check_path (struct vectors * vecs, struct path * pp,
> int ticks)
>                                   pp->checkint = conf->checkint;
>                                   put_multipath_config(conf);
>
> -                                  if (newstate == PATH_DOWN || newstate
> == PATH_SHAKY) {
> +                                  if (newstate == PATH_DOWN || newstate
> == PATH_SHAKY || newstate == PATH_TIMEOUT) {
>                                                    /*
>                                                     * proactively fail
> path in the DM
>                                                     */
> --
> 2.8.1.windows.1
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20161011/7fd1cc53/attachment.htm>