[dm-devel] [PATCH 06/12] multipathd: fix device creation issues

[Martin Wilck]

On Thu, 2017-12-07 at 12:49 -0600, Benjamin Marzinski wrote:
> Right now, devices created by multipath and added to multipthd via
> ev_add_map() are setup up incorrectly until the first time they get
> reloaded.  setup_map() is not run on these devices, which means that
> all
> of the multipath variables set up there don't get initialized until a
> later reload.  Also, adopt_paths is run to pull in any paths that the
> device is missing, but the device is never reloaded afterwards, so
> these
> paths aren't used.
> 
> Now, add_map_without_path() sets up the basic multipath device
> variables
> and then calls update_map() to finish the setup and reload the
> device.
> This patch also moves the code in __setup_multipath(), that only
> existed
> to handle adding devices via ev_add_map(), to where it belongs.
> 
> However, it is possible to create a device with no paths, which means
> the device cannot know which hwentry to use for its device
> configuration.  __setup_multipath() used to help with this via
> extract_hwe_from_path(), which grabbed the hwentry from a path if the
> multipath device didn't already have it set. This is now done both
> when
> paths are added or the map is updated, which means that
> extract_hwe_from_path() runs before the device is configured in
> setup_map() instead of after the table has already been loaded. This
> is
> a good thing. But because of this, it can't check the dmstate or the
> pathgroup state.  I don't believe it's necessary to care what state
> the
> path is in, especially now that we use libudev. The vendor and
> product
> information gets cached by libudev when the path device is first
> added,
> and should remain the same regardless of whether or not the device is
> currently up.  My version does try to take the hwe information from a
> path in the PATH_UP state first, but this is mostly to satisfy the
> paranoia of the old version.
> 
> Also, map_discovery(), which creates multipath devices during
> multipathd
> startup and reconfiguration, that only exist to see if multipathd
> needs
> to reload the device table, called __setup_multipath() as well. Even
> after removing the unnecessary code from __setup_multpiath, that
> still
> does pointless work for these devices, which will be removed before
> the
> end of configure(). Now, map_discovery() just gets the necessary
> kernel
> information to make the correct call in select_action().
> 
> Signed-off-by: Benjamin Marzinski <bmarzins at redhat.com>

Reviewed-by: Martin Wilck <mwilck at suse.com>

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