Hello Ben,
On Tue, 2023-02-07 at 18:32 -0600, Benjamin Marzinski wrote:
> If "multipath -u" fails, udev doesn't import any values from the
> program. This means that multipath.rules will continue to use the
> values
> for DM_MULTIPATH_DEVICE_PATH and FIND_MULTIPATHS_WAIT_UNTIL that it
> has
> already imported from the database. This is the correct thing to do
> for
> every case except the MAYBE case for "find_multipaths smart". In that
> case, DM_MULTIPATH_DEVICE_PATH will be set to 1, and the rules will
> assume that the device has been definitively claimed.
>
> In this case, we know that the device shouldn't have been claimed
> before, but we don't know if it should be claimed now, or if we have
> hit
> the timeout and it should be released, since we didn't get any
> information from multipath. The safest thing to do is assume that
> this
> was the timeout, and the device shouldn't be claimed. The only time
> when
> this could be the wrong answer is when we first see a new multipath
> device, and it could only cause problems if there is metadata on the
> device that will cause it to get autoassembled by something else,
> before
> multipathd can autoassemble it. If we assume that it is a multipath
> device, or we assume that this wasn't actually the timeout uevent, we
> can keep a necessary device from getting released to the reset of the
> system.
>
> Signed-off-by: Benjamin Marzinski <bmarz...@redhat.com>
We have this code in check_path_valid():
/*
* multipath -u must exit with status 0, otherwise udev won't
* import its output.
*/
if (!is_uevent && r == PATH_IS_NOT_VALID)
r = RTVL_FAIL;
else
r = RTVL_OK;
AFAICS about the only condition I can imagine in which "multipath -u"
would return an exit status other than 0 would be failure of
init_config(). If that's the case you're concerned about, the issue
might be easier to fix in main.c directly.
Regards,
Martin
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
