On Fri, 2017-02-17 at 15:41 +0800, tang.junhui@xxxxxxxxxx wrote: > > Hello Ben, > > It's too later now, I think you'd better go bed, haha. > > ＞ ＞ ＞ The first case should have been reduced to "remove path1 | > remove path2 > ＞ ＞ ＞ | add path3" by filtering beforehand. I suppose you want to > avoid this > ＞ ＞ ＞ sequence because it could leave us without paths temporarily, > causing > ＞ ＞ ＞ multipathd to destroy the map. But I don't understand what > "stop > ＞ ＞ ＞ merging" buys you here - if you process the events one-by-one, > you may > ＞ ＞ ＞ also have 0 paths at some point. > ＞ ＞ > ＞ ＞ Well, because of the filtering , you will never actually stop > merging > ＞ ＞ in this case, like you mentioned. > ＞ > ＞ Or, if I actually read better, I would see that you will stop > merging. > ＞ I can't think of any problems in theory with merging adds after > removes > ＞ in the simple case at least. > Maybe we can merger more uevents without stopping mergering(Like > even > merge "add uevent" and "remove uevent" ), but what I have right now > handles > the common cases, which are bursts of add/chage events, and bursts of > remove > events. So when we meet the complex scene, we'd better stop > mergering, > and just let them be processed one by one. It can reduce abnormal > situation, > and enhance the reliability of the code. As I wrote in my previous mail, I am not sure if one-by-one processing is really safer. We are considering a situation where paths for one WWID are rapidly coming and going at the same time. In that situation it's inevitable that the kernel and multipathd get out of sync, and care needs to be taken not to destroy the multipath device prematurely. Because uevents are unreliable and relatively slow, it may actually be a good idea to pause processing them altogether. But again, I'm not expecting you to fix this in this patch set. It's just something we should keep in mind. And it's a good thing that you're trying not to break stuff :-) Regards Martin -- Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
