Hi Martin: Thanks for your detailed explanation. I understand it well. Regards Lixiaokeng On 2020/8/20 23:22, Martin Wilck wrote: > 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
