On Wed, Jul 02, 2025 at 12:09:33AM +0200, Martin Wilck wrote: > After manually failing some paths and then reinstating them, the > following pattern of events has been observed: > > [1535664.790944] localhost multipathd[26335]: mpathc: reinstate path 8:48 (operator) > [1535664.791422] localhost multipathd[26335]: mpathc: devmap event #4 > [1535664.793140] localhost kernel: device-mapper: multipath: 254:6: Reinstating path 8:48. > [1535665.219024] localhost multipathd[26335]: mpathc: reload [0 125829120 multipath 1 queue_if_no_path 1 alua 2 1 queue-length 0 2 1 8:144 1 8:240 1 queue-length 0 2 1 8:48 1 65:80 1] > [1535665.290268] localhost multipathd[26335]: sync_map_state: failing sdd state 2 dmstate 2 > [1535665.292442] localhost kernel: device-mapper: multipath: 254:6: Failing path 8:48. > [1535669.291320] localhost multipathd[26335]: sdd: tur state = up > [1535669.291531] localhost multipathd[26335]: mpathc: sdd - tur checker reports path is up > [1535669.291531] localhost multipathd[26335]: 8:48: reinstated > > We see that sdd (8:48) is first reinstated, then failed again during > the reload operation, and finally reinstated in the checker. > > This happens because multipathd doesn't update the internal path state when it > calls dm_reinstate_path(). If sync_map_state() is called, it will see the path > in PATH_DOWN state and fail the path again. > > Fix it by setting pp->state to PATH_UNCHECKED. > > Signed-off-by: Martin Wilck <mwilck@xxxxxxxx> Reviewed-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
