On Tuesday 24 February 2004 11:04 am, christophe.varoqui@xxxxxxx 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@xxxxxxxxxx http://evms.sourceforge.net/