Linux Device Mapper development
 help / color / mirror / Atom feed
From: "Benjamin Marzinski" <bmarzins@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: dm-devel@redhat.com
Subject: Re: [PATCH 5/5] multipathd: decrease log level of uevent messages
Date: Fri, 21 Sep 2018 18:00:32 -0500	[thread overview]
Message-ID: <20180921230032.GP3172@octiron.msp.redhat.com> (raw)
In-Reply-To: <20180914125103.1154-5-mwilck@suse.com>

On Fri, Sep 14, 2018 at 02:51:03PM +0200, Martin Wilck wrote:

I agree that these messages are largely useless for users, but I often
find them helpful to figure out what multipath was doing when things go
badly.  I'm not against this patch going in. I just wish that log there
was a log level between 2 and 3 that just included notifications about
what was happening, instead of having to go to level 3 to get the
information, which adds a lot of debugging noise. Any way

Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>

> The messages "multipathd: add path (uevent)" etc. are displayed
> frequently, and often for devices that don't matter for multipathd.
> If real action needs to be taken, such as adding or removing paths
> or maps from the internal structures, multipathd emits other log
> messages at level 2 later on.
> 
> Signed-off-by: Martin Wilck <mwilck@suse.com>
> ---
>  multipathd/main.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/multipathd/main.c b/multipathd/main.c
> index cc493c18..bc95c65f 100644
> --- a/multipathd/main.c
> +++ b/multipathd/main.c
> @@ -743,7 +743,7 @@ uev_remove_map (struct uevent * uev, struct vectors * vecs)
>  	int minor;
>  	struct multipath *mpp;
>  
> -	condlog(2, "%s: remove map (uevent)", uev->kernel);
> +	condlog(3, "%s: remove map (uevent)", uev->kernel);
>  	alias = uevent_get_dm_name(uev);
>  	if (!alias) {
>  		condlog(3, "%s: No DM_NAME in uevent, ignoring", uev->kernel);
> @@ -803,7 +803,7 @@ uev_add_path (struct uevent *uev, struct vectors * vecs, int need_do_map)
>  	int ret = 0, i;
>  	struct config *conf;
>  
> -	condlog(2, "%s: add path (uevent)", uev->kernel);
> +	condlog(3, "%s: add path (uevent)", uev->kernel);
>  	if (strstr(uev->kernel, "..") != NULL) {
>  		/*
>  		 * Don't allow relative device names in the pathvec
> @@ -911,7 +911,8 @@ ev_add_path (struct path * pp, struct vectors * vecs, int need_do_map)
>  	     (pathcount(mpp, PATH_GHOST) > 0 && pp->tpgs != TPGS_IMPLICIT &&
>  	      mpp->ghost_delay_tick <= 0))) {
>  		/* if wait_for_udev is set and valid paths exist */
> -		condlog(2, "%s: delaying path addition until %s is fully initialized", pp->dev, mpp->alias);
> +		condlog(3, "%s: delaying path addition until %s is fully initialized",
> +			pp->dev, mpp->alias);
>  		mpp->wait_for_udev = 2;
>  		orphan_path(pp, "waiting for create to complete");
>  		return 0;
> @@ -1038,7 +1039,7 @@ uev_remove_path (struct uevent *uev, struct vectors * vecs, int need_do_map)
>  	struct path *pp;
>  	int ret;
>  
> -	condlog(2, "%s: remove path (uevent)", uev->kernel);
> +	condlog(3, "%s: remove path (uevent)", uev->kernel);
>  	delete_foreign(uev->udev);
>  
>  	pthread_cleanup_push(cleanup_lock, &vecs->lock);
> -- 
> 2.18.0

  reply	other threads:[~2018-09-21 23:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-14 12:50 [PATCH 1/5] libmultipath: nvme: fix path detection for kernel 4.16 Martin Wilck
2018-09-14 12:51 ` [PATCH 2/5] libmultipath: nvme: shorter topology output Martin Wilck
2018-09-21 22:51   ` Benjamin Marzinski
2018-09-14 12:51 ` [PATCH 3/5] libmultipath: pathinfo: skip hidden devices Martin Wilck
2018-09-21 22:52   ` Benjamin Marzinski
2018-09-14 12:51 ` [PATCH 4/5] multipathd: fix version check for DM_DEV_ARM_POLL ioctl Martin Wilck
2018-09-21 22:52   ` Benjamin Marzinski
2018-09-14 12:51 ` [PATCH 5/5] multipathd: decrease log level of uevent messages Martin Wilck
2018-09-21 23:00   ` Benjamin Marzinski [this message]
2018-09-21 22:51 ` [PATCH 1/5] libmultipath: nvme: fix path detection for kernel 4.16 Benjamin Marzinski

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=20180921230032.GP3172@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