From: Martin Wilck <mwilck@suse.de>
To: Benjamin Marzinski <bmarzins@redhat.com>,
Christophe Varoqui <christophe.varoqui@opensvc.com>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH 8/9] libmutipath: continue to use old state on PATH_PENDING
Date: Tue, 26 Feb 2019 11:12:47 +0100 [thread overview]
Message-ID: <308cf00c2437770c538a8c35717eb9dfdafe60ec.camel@suse.de> (raw)
In-Reply-To: <1550854692-19873-9-git-send-email-bmarzins@redhat.com>
On Fri, 2019-02-22 at 10:58 -0600, Benjamin Marzinski wrote:
> When pathinfo() sets pp->state to PATH_PENDING, it can cause problems
> with path checking. It should act more like check_path(). When
> check_path() sees a new state of PATH_PENDING, it doesn't update the
> path state at all, so a path's old state is normally never
> PATH_PENDING.
>
> As and example of the problems of setting a path to PATH_PENDING, If
> check_path() sets a path's state to PATH_UP, then a call to
> pathinfo()
> sets the state to PATH_PENDING, and then another call the
> check_path()
> sets the state to PATH_DOWN, multipathd won't fail the path in the
> kernel.
I can see what you mean, but I'm unsure how this example would come to
pass in practice (AFAICS, pathinfo(DI_CHECKER) is only called during
path discovery / reconfigure(), or when new paths are detected /
added).
> Also, if a path's state is PATH_PENDING, and nr_active is
> recalculated, that path will count as down, even if the state was
> previously PATH_UP.
Ah, this is how you deal with what I remarked on the second hunk of
patch 6/9. This is smart.
> If a path already has a state of PATH_WILD or
> PATH_UNCHECKED, changing it to PATH_PENDING won't hurt anything, and
> it
> will help anyone who sees it know what's actually happening. But
> otherwise, pathinfo() should leave the previous state alone.
>
> Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
> ---
> libmultipath/discovery.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
My gut feeling is that we should distinguish between the case where
PATH_PENDING is set in path_offline() (sysfs state "quiesce",
"blocked", "pending" etc.), and the case where the async checker is
simply not finished yet. The first case does tell us something about
the path (being temporarily inaccessible), whereas the second basically
just says that we're ignorant.
Anyway, that's future work, so:
Reviewed-by: Martin Wilck <mwilck@suse.com>
>
> diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
> index 729bcb9..d3585f9 100644
> --- a/libmultipath/discovery.c
> +++ b/libmultipath/discovery.c
> @@ -1946,8 +1946,11 @@ int pathinfo(struct path *pp, struct config
> *conf, int mask)
>
> if (mask & DI_CHECKER) {
> if (path_state == PATH_UP) {
> - pp->chkrstate = pp->state = get_state(pp, conf,
> 0,
> - path_stat
> e);
> + int newstate = get_state(pp, conf, 0,
> path_state);
> + if (newstate != PATH_PENDING ||
> + pp->state == PATH_UNCHECKED ||
> + pp->state == PATH_WILD)
> + pp->chkrstate = pp->state = newstate;
> if (pp->state == PATH_TIMEOUT)
> pp->state = PATH_DOWN;
> if (pp->state == PATH_UP && !pp->size) {
next prev parent reply other threads:[~2019-02-26 10:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 16:58 [PATCH 0/9] Misc Multipath patches Benjamin Marzinski
2019-02-22 16:58 ` [PATCH 1/9] libmultipath: disable user_friendly_names for NetApp Benjamin Marzinski
2019-02-26 8:43 ` Martin Wilck
2019-02-22 16:58 ` [PATCH 2/9] libmultipath: handle existing paths in marginal_path enqueue Benjamin Marzinski
2019-02-22 16:58 ` [PATCH 3/9] multipathd: cleanup marginal paths checking timers Benjamin Marzinski
2019-02-22 16:58 ` [PATCH 4/9] libmultipath: fix marginal paths queueing errors Benjamin Marzinski
2019-02-22 16:58 ` [PATCH 5/9] libmultipath: fix marginal_paths nr_active check Benjamin Marzinski
2019-02-22 16:58 ` [PATCH 6/9] multipathd: Fix miscounting active paths Benjamin Marzinski
2019-02-26 9:15 ` Martin Wilck
2019-02-26 10:16 ` Martin Wilck
2019-02-22 16:58 ` [PATCH 7/9] multipathd: ignore failed wwid recheck Benjamin Marzinski
2019-02-26 9:42 ` Martin Wilck
2019-02-26 20:29 ` Benjamin Marzinski
2019-02-22 16:58 ` [PATCH 8/9] libmutipath: continue to use old state on PATH_PENDING Benjamin Marzinski
2019-02-26 10:12 ` Martin Wilck [this message]
2019-02-26 20:37 ` Benjamin Marzinski
2019-02-22 16:58 ` [PATCH 9/9] multipathd: use update_path_groups instead of reload_map Benjamin Marzinski
2019-02-26 10:47 ` Martin Wilck
2019-02-26 22:32 ` Benjamin Marzinski
2019-02-27 10:22 ` Martin Wilck
2019-02-26 10:50 ` [PATCH 0/9] Misc Multipath patches Martin Wilck
2019-02-26 15:10 ` Martin Wilck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=308cf00c2437770c538a8c35717eb9dfdafe60ec.camel@suse.de \
--to=mwilck@suse.de \
--cc=bmarzins@redhat.com \
--cc=christophe.varoqui@opensvc.com \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox