ok, here is a design I suggest to code :
2 threaded beast :
* thread 1 : loop in {update failed path list; wait for DM event}
* thread 2 : loop in {submit test IOs to failed paths; sleep}
if test IO succeeds, exec the multipath config tool for this path, which will
reset all paths for the multipath to their active state.
Investigating this, I come across an interesting problem : how, in our modern
Linux world, do we resolve major,minor (as given by DM_DEVICE_STATUS) to node
name (as needed for submiting test IO) ?
On another note I report some strange behaviours with 2.6.3-udm3 :
* dmsetup wait blocks until the first event (right), but relunching the same cmd
returns immediatly. This would put thread 1 in tight loop after the first event.
* the multipath config tool and dmsetup in config modes block when exec'ed on a
multipath with not active path. This would annoy thread 2.
* overall, the path failing in the kernel seems weak : I have a scenario that in
know would bring down all paths that the kernel doesn't cope well (1 path
correctly marked failed, 150 MB/s on 3 paths that shouldn't be up anymore)
regards,
cvaroqui
Ideas welcome.
--
