> I'm not against your idea, but the way to code is now, even doing > your > mpp loop doesn't really guarantee that. Just because all the paths > get > checked every 20 seconds, doesn't mean that they will be ready to be > checked on the same second. For paths that get added after the > multipath > device is created, this is often not the case. And even if the paths > start in sync, there are multiple reasons why they can drop out of > sync. True. I am not claiming my idea was perfectly thought through. But I think the issues you mention could be overcome. For example, we might check all "healthy" paths of a map at the same time. If a path goes down and back up again, it might get out of sync with this "rhythm" the way we handle it now, but we might as well just treat it like the other healthy paths again. > > But it we wanted to, we probably could fix that and space the > checkers > out better at the same time. I don't think it would be that hard to > make > the paths change their next check tick by a second every so often so > that > all the paths in the same state from a given multipath device run > their > checkers at the same time. We could even make the different multipath > devices spread out when they are checked, so that they aren't trying > to > all run their checkers at once. Interesting idea, even though I think that once we do truly asynchronous path checking, that won't be much of an issue any more. > > I'll take a stab at this in my updated patchset. Ok, looking forward to it. Martin > > -Ben > > > In the long run, I think what we should do is use asynchronous > > checkers > > exclusively. And instead of waiting a millisecond for them to > > complete > > synchronously, we should trigger the path check on all paths (that > > need > > to be checked) in one go, then wait for all checkers to complete > > (this > > is the difficult part, I know), and then go over all the results, > > again > > without waiting for anything. > > > > Another project I've been wanting to do for a long time :-/ > > > > Regards > > Martin > > >
