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. --