On Thu, 2021-12-02 at 19:34 -0600, Benjamin Marzinski wrote:
> When multipathd gets a change event for a multipath device, the dm
> info
> may have changed, so update it.
>
> Signed-off-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
> ---
> multipathd/main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/multipathd/main.c b/multipathd/main.c
> index 7a57a798..5cb70575 100644
> --- a/multipathd/main.c
> +++ b/multipathd/main.c
> @@ -818,6 +818,7 @@ ev_add_map (char * dev, const char * alias,
> struct vectors * vecs)
> conf = get_multipath_config();
> reassign_maps = conf->reassign_maps;
> put_multipath_config(conf);
> + dm_get_info(mpp->alias, &mpp->dmi);
> if (mpp->wait_for_udev) {
> mpp->wait_for_udev = 0;
> if (get_delayed_reconfig() &&
Reviewed-by: Martin Wilck <mwilck@xxxxxxxx>
Note for future development: I just realized that dm_get_info() would
also get called in the dmevent handler. We currently do some duplicate
work in both handlers.
In theory at least, we could look at the event_nr field and see whether
this event has already been handled by ourselves. If the dmevent
handler sees that uevent kicked in first, it wouldn't need to do
anything. The uevent handler would only need to look at properties that
udev might have added, but wouldn't need to do a full setup_multipath()
any more.
Regards,
Martin
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
