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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
