[dm-devel] [PATCH 3/5] multipathd: add reclear_pp_from_mpp in ev_remove_path

[Martin Wilck]

On Thu, 2020-08-20 at 22:51 +0800, lixiaokeng wrote:
> Hi Martin:
>    I test this in 0.8.4 without your patch series . I have review the
> code with your patch series and I think this problem will be solved.
> But I have another question.
> ev_remove_path
> 	->__setup_multipath
> 		->update_multipath_strings
> 			->update_multipath_table
> 				->update_pathvec_from_dm
> 					->store_path
> When multipathd del path xxx(such as sde) and multipath -v2 are
> executed simultaneously, will the path(sde) deleted be stored to
> pathvec
> again? In my opinion, sde is't delete in pathvec and in
> disassembel_map
> sde will be stored to mpp->pg. When update_pathvec_from_dm, sde will
> be
> stored again.

in ev_remove_path(), we set INIT_REMOVED state. That means this path
won't be used in the RELOAD ioctl. If the ioctl is successful, it will
be gone from the kernel (for the time being). Later, sync_map_state()
will figure this out, and remove the path. If the parallel "multipath"
command reloads the map after multipathd's RELOAD operation, and before
update_multipath_table() called, re-adding the path, the path will be
read back from the kernel, and sync_map_state() will not delete the it.
>From multipathd's point of view it will remain in INIT_REMOVED state,
though. multipathd will not try to reload the map again unless it's
asked to do so with another "add path" or "del path" command. This
results in an inconsistent internal state between multipathd and the
kernel (multipathd considers the path as REMOVED even though it's still
present in the map). I don't think this can be generally avoided if we
allow multipath to make changes to kernel maps while multipathd is
running. (*)

We could avoid this by delegating these commands from multipath to
multipathd, as we already do for some other commands. "multipath"
without any arguments would map to a "multipathd reconfigure" command,
while "multipath $DEVICE" would be translated to "multipathd add map"
or "multipathd add path".

Does this make sense?

Regards,
Martin

(*) Well: we *could* try to analyze incoming uevents, and distinguish
those that multipathd has initiated itself from other, externally-
triggered ones. Then if an external event arrives, adding a path which
we had previously removed, and this external event arrives after the
remove event we initiated, we could in theory infer that an external
program had reverted the change we just made. But this would result in
complex and pretty fragile logic. I'm not sure if it's worth it. The
"delegating" approach is safer and cleaner IMO.