On Tue, Jan 14, 2025 at 10:37:24PM +0100, Martin Wilck wrote: > On Thu, 2024-12-19 at 16:57 -0500, Benjamin Marzinski wrote: > > On Wed, Dec 11, 2024 at 11:58:59PM +0100, Martin Wilck wrote: > > > After reading the kernel device-mapper table, > > > update_pathvec_from_dm() > > > sets the mpp->need_reload flag if an inconsistent state was found > > > (often a > > > path with wrong WWID). We expect reload_and_sync_map() to fix this > > > situation. > > > However, schedule a quick resync in this case, to be double-check > > > that the > > > inconsistency has been fixed. > > > > I'm not too sure about this. My biggest worry with handling > > mpp->need_reload in the checkerloop is what happens if for some > > reason > > multipathd and the kernel keep disagreeing on something. You would > > just > > keep reloading the device. That seems unlikely, so I've o.k. with > > handling it here, but if that does happen, this would make it much > > worse. Instead of reloading every path check, you would reload every > > loop. > > > > If you do detect an inconsistent state, and trigger a reload, and the > > state is still inconsistent after that, I would argue that yet > > another > > reload is more likely to remain inconsistent than it is to fix the > > problem. So I would rather not speed it up. > > > > Please see my reply to 03/14. Fine. Since I can see situations where a cascade of device changes would make an inconsistency appear immediately after a reload and I can't actually come up with a case (excluding bugs and ENOMEM) where nothing changed, and we reloaded to fix and inconsistency, but it still isn't fixed, we should probably handle the case that we know can actually happen. Warning on inconsistent states should be good enough, and I think we already do that in update_pathvec_from_dm(). -Ben > > Martin
