[dm-devel] [RFC] pathchecker

[christophe varoqui]

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