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.
Thanks
* 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
regards,
cvaroqui
