dm-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "Benjamin Marzinski" <bmarzins@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: tang.junhui@zte.com.cn, zhang.kai16@zte.com.cn,
	dm-devel@redhat.com, Bart Van Assche <bart.vanassche@sandisk.com>
Subject: Re: Improve processing efficiency for addition and deletion of multipath devices
Date: Mon, 28 Nov 2016 11:31:24 -0600	[thread overview]
Message-ID: <20161128173124.GE1972@octiron.msp.redhat.com> (raw)
In-Reply-To: <1480328936.23852.10.camel@suse.com>

On Mon, Nov 28, 2016 at 11:28:56AM +0100, Martin Wilck wrote:
> On Mon, 2016-11-28 at 10:19 +0800, tang.junhui@zte.com.cn wrote:
> > 
> > 4.        Proposal 
> > Other than processing uevents one by one, uevents which coming from
> > the 
> > same LUN devices can be mergered to one, and then uevent processing 
> > thread only needs to process it once, and it only produces one DM
> > addition 
> > uevent which could reduce system resource consumption. 
> > 
> 
> Here comes an idea how to achieve this without a lot of additional
> code:
> 
> libmultipath already has code to check whether any maps need to be
> updated (in coalesce_paths()). Instead of recording uevents, merging
> them, and calling ev_add_path() for every affected WWID, it might be
> sufficient to set daemon state to DAEMON_CONFIGURE and wake up the main
> multipathd thread to call reconfigure(). Then we only need to make sure
> that coalesce_paths() really reloads or creates maps only when
> necessary. I have some patches here that I made for that purpose, for a
> different scenario (multipathd to avoid RELOAD ioctls when it's started
> in a scenario where most paths are already set up by udev).

There is a long standing multipath issue that this will likely make a
lot worse.  Currently, multipathd can drop paths that it doesn't have
access to on reconfigure. This is wrong. When the path comes back, it
won't issue another add uevent. This means that multipathd won't be able
to re-enable it (since it stopped monitoring it during the reconfigure).
In fact the only way to get the path back is to either manually
intervene or to have the path actually get removed from the system and
come back.

The correct thing for multipath to do is to only remove paths when it is
manually instructed to, when a reconfigure blacklists the path, or when
it gets a remove uevent.  Now currently this isn't a huge issue since
people don't commonly reconfigure their multipath device, but it we
start running reconfigure all the time, it certainly will become one.

-Ben
 
> Regards
> Martin
> 
> -- 
> Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

  reply	other threads:[~2016-11-28 17:31 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-28  2:19 Improve processing efficiency for addition and deletion of multipath devices tang.junhui
2016-11-28 10:05 ` Hannes Reinecke
2016-11-28 16:07   ` Benjamin Marzinski
2016-11-28 16:26     ` Zdenek Kabelac
2016-11-28 10:06 ` Zdenek Kabelac
2016-11-28 10:42   ` Hannes Reinecke
2016-11-28 11:51     ` Zdenek Kabelac
2016-11-28 12:06       ` Peter Rajnoha
2016-11-28 12:08       ` Hannes Reinecke
2016-11-28 12:23         ` Peter Rajnoha
2016-11-28 12:55         ` Zdenek Kabelac
2016-11-28 17:22         ` Benjamin Marzinski
2016-11-29  9:34           ` Zdenek Kabelac
2016-11-28 10:28 ` Martin Wilck
2016-11-28 17:31   ` Benjamin Marzinski [this message]
2016-11-29  7:52     ` Martin Wilck
2016-11-29 19:21       ` Benjamin Marzinski
2016-11-28 15:25 ` Benjamin Marzinski
2016-11-28 15:37   ` Hannes Reinecke
2016-12-01  1:16     ` tang.junhui
  -- strict thread matches above, loose matches on Subject: below --
2016-11-16  1:46 tang.junhui
2016-11-16  7:53 ` Hannes Reinecke
2016-11-16  8:45   ` tang.junhui
2016-11-16  9:49     ` Martin Wilck
2016-11-17  1:41       ` tang.junhui
2016-11-17 10:48         ` Martin Wilck
2016-11-18  1:02           ` tang.junhui
2016-11-18  7:39             ` Martin Wilck
2016-11-18  8:24               ` tang.junhui
2016-11-18  8:30                 ` Martin Wilck
2016-11-18  8:56                   ` tang.junhui
2016-11-18  9:12                   ` tang.junhui
2016-11-21 18:19                   ` Benjamin Marzinski
2016-11-18 22:26           ` Benjamin Marzinski
2016-11-23  1:08             ` tang.junhui
2016-11-29  9:07               ` Zdenek Kabelac
2016-11-29 10:13                 ` tang.junhui
2016-11-24  9:21             ` Martin Wilck
2016-11-28 18:46               ` Benjamin Marzinski
2016-11-29  6:47                 ` Hannes Reinecke
2016-11-29  8:02                   ` Martin Wilck
2016-11-29  8:10                     ` Zdenek Kabelac
2016-11-29  8:16                       ` Martin Wilck
2016-11-29  8:24                         ` Zdenek Kabelac
2016-11-29 17:25                     ` Benjamin Marzinski
2016-11-29  7:57                 ` Martin Wilck
2016-11-29 17:41                   ` 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=20161128173124.GE1972@octiron.msp.redhat.com \
    --to=bmarzins@redhat.com \
    --cc=bart.vanassche@sandisk.com \
    --cc=dm-devel@redhat.com \
    --cc=mwilck@suse.com \
    --cc=tang.junhui@zte.com.cn \
    --cc=zhang.kai16@zte.com.cn \
    /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;
as well as URLs for NNTP newsgroup(s).