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

Re: [dm-devel] [RFC] pathchecker



On Tuesday 24 February 2004 11:04 am, christophe varoqui free fr wrote:
> 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.

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

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

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

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

Not sure what to say about this. :(  Maybe Joe has a suggestion.

-- 
Kevin Corry
kevcorry us ibm com
http://evms.sourceforge.net/



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