From: "Benjamin Marzinski" <bmarzins@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: dm-devel@redhat.com
Subject: Re: [PATCH 8/8] multipathd: handle repeated udev retrigger failure
Date: Fri, 12 Oct 2018 17:30:46 -0500 [thread overview]
Message-ID: <20181012223046.GK29125@octiron.msp.redhat.com> (raw)
In-Reply-To: <20181010200506.15796-9-mwilck@suse.com>
On Wed, Oct 10, 2018 at 10:05:06PM +0200, Martin Wilck wrote:
> If a path was still not properly initialized after exhausting the
> retrigger tries, it used to remain in INIT_MISSING_UDEV state forever.
> get_uid() might fall back to non-udev-based methods to determine
> the WWID, but it would never be called for a path in this state any more.
>
> This patch changes this behavior by resetting the path back to FAILED
> state if udev can't provide the WWID even after retriggering. Now, if
> the path ever happens to be in PATH_UP or PATH_GHOST state again,
> pathinfo(DI_ALL) will be called from check_path(), and there's at least
> some chance to obtain a WWID for it.
What you have seems reasonable, but looking at the code that calls
pathinfo() in this case, I do have some related suggestions.
Since check_path() always returns early if !pp->mpp and
pp->initialized != INIT_FAILED, we don't need the
pp->initialized != INIT_MISSING_UDEV check before doing the pathinfo
(although we might want to check pp->initialized == INIT_FAILED, in case
we add other pp->initialized states in the future).
Also, I don't think that checking if pathinfo returns PATHINFO_OK is the
right thing to do before calling ev_add_path(). pathinfo() will return
PATHINFO_OK even if we fail to get the wwid. I'm pretty sure this should
check if pp->initialized == INIT_OK instead.
Finally, if pp->initialized != INIT_OK after the call to pathinfo(),
would you object to setting pp->tick to max_checkint so that we don't
keep checking the path as often. It is possible that this really is a
device that shouldn't be multipathed, and for which we will never be
able to get a wwid. It seems like after some many failures, we don't
need to be so proactive about rechecking an active path where we simply
aren't getting the wwid.
-Ben
>
> Signed-off-by: Martin Wilck <mwilck@suse.com>
> ---
> multipathd/main.c | 32 +++++++++++++++++++++++---------
> 1 file changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/multipathd/main.c b/multipathd/main.c
> index 2d45d989..a9e1a4bd 100644
> --- a/multipathd/main.c
> +++ b/multipathd/main.c
> @@ -1828,15 +1828,29 @@ check_path (struct vectors * vecs, struct path * pp, int ticks)
> retrigger_tries = conf->retrigger_tries;
> checkint = conf->checkint;
> put_multipath_config(conf);
> - if (!pp->mpp && pp->initialized == INIT_MISSING_UDEV &&
> - pp->retriggers < retrigger_tries) {
> - condlog(2, "%s: triggering change event to reinitialize",
> - pp->dev);
> - pp->initialized = INIT_REQUESTED_UDEV;
> - pp->retriggers++;
> - sysfs_attr_set_value(pp->udev, "uevent", "change",
> - strlen("change"));
> - return 0;
> + if (!pp->mpp && pp->initialized == INIT_MISSING_UDEV) {
> + if (pp->retriggers < retrigger_tries) {
> + condlog(2, "%s: triggering change event to reinitialize",
> + pp->dev);
> + pp->initialized = INIT_REQUESTED_UDEV;
> + pp->retriggers++;
> + sysfs_attr_set_value(pp->udev, "uevent", "change",
> + strlen("change"));
> + return 0;
> + } else {
> + condlog(1, "%s: not initialized after %d udev retriggers",
> + pp->dev, retrigger_tries);
> + /*
> + * Make sure that the "add missing path" code path
> + * below may reinstate the path later, if it ever
> + * comes up again.
> + * The WWID needs not be cleared; if it was set, the
> + * state hadn't been INIT_MISSING_UDEV in the first
> + * place.
> + */
> + pp->initialized = INIT_FAILED;
> + return 0;
> + }
> }
>
> /*
> --
> 2.19.0
next prev parent reply other threads:[~2018-10-12 22:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-10 20:04 [PATCH 0/8] various multipath-tools patches Martin Wilck
2018-10-10 20:04 ` [PATCH 1/8] test-kpartx: add test for invocation on image file Martin Wilck
2018-10-12 21:45 ` Benjamin Marzinski
2018-10-10 20:05 ` [PATCH 2/8] libmultipath: scsi_ioctl_pathinfo doesn't fail Martin Wilck
2018-10-12 21:46 ` Benjamin Marzinski
2018-10-10 20:05 ` [PATCH 3/8] libmultipath: cciss_ioctl_pathinfo " Martin Wilck
2018-10-12 21:47 ` Benjamin Marzinski
2018-10-10 20:05 ` [PATCH 4/8] multipath.rules: add comment about DM_MULTIPATH_DEVICE_PATH=2 Martin Wilck
2018-10-12 21:49 ` Benjamin Marzinski
2018-10-10 20:05 ` [PATCH 5/8] multipath.8: man page update Martin Wilck
2018-10-12 21:51 ` Benjamin Marzinski
2018-10-10 20:05 ` [PATCH 6/8] libmultipath: test code for "zombie" TUR threads Martin Wilck
2018-10-12 21:51 ` Benjamin Marzinski
2018-10-10 20:05 ` [PATCH 7/8] libmultipath: handle TUR threads that can't be cancelled Martin Wilck
2018-10-12 22:11 ` Benjamin Marzinski
2018-10-23 10:58 ` Martin Wilck
2018-10-10 20:05 ` [PATCH 8/8] multipathd: handle repeated udev retrigger failure Martin Wilck
2018-10-12 22:30 ` Benjamin Marzinski [this message]
2018-10-13 8:48 ` [PATCH 0/8] various multipath-tools patches Christophe Varoqui
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=20181012223046.GK29125@octiron.msp.redhat.com \
--to=bmarzins@redhat.com \
--cc=dm-devel@redhat.com \
--cc=mwilck@suse.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