[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [RFC] pathchecker

Kevin Corry wrote:
if test IO succeeds, exec the multipath config tool for this path, which
will reset all paths for the multipath to their active state.

Will this reactivate *all* paths, or just the path that's known to have recovered?

*all* :)
like the initial config does ...
yes, it is suboptimal, but how disturbing ? I don't even know how to activate individual paths. Maybe with path options in tha path list of the PG definition ?

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) ?

#include <sys/types.h>
dev_t devt = makedev(major, minor);
mknod("/some/path/name", S_IFBLK | S_IRUSR | S_IWUSR, devt);

Then use "/some/path/name" for testing the path.

That's smart, thanks

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.

You need to specify an event number when waiting on the device. Each time an event occurs, you need to increment your event number. Also, keep in mind that multiple events could occur before you're able to begin the next wait command. If so, you'll see the above behavior, where DM will simply return an error until you wait on a valid event number.


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

What command are you issuing to dmsetup that blocks?

suspend for example


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]