[dm-devel] [PATCH][RFC] supporting different failover models

Mike Christie michaelc at cs.wisc.edu
Wed Feb 11 17:06:07 UTC 2004


Hey Joe,

A good use of the Priority Group framework is to place your primary 
paths in one group and your secondary, tertiary, etc paths in a higher 
groups. The problem is that some devices will require a special command 
be sent before the other paths can be used. And another class of devices 
will simply perform the switch when IO is sent down the secondary paths.

For the latter group of devices the test IOs are going to cause switches 
which is going to cause performance problems. By only testing the 
current group or specifying which groups should be tested and just 
seperating your paths through priority groups, we can avoid that 
problem, you do not have to worry about revalidating secondary paths 
that were previously initially failed, plus I think you can then kill 
the nr_tested_paths code.

All that is needed to support the devices that require a special command
are some callouts in the priority group framework to initialize the
group before it is used. If this is done from the daemon we can sleep 
and wait for the result, and you have already provided a way to queue 
incoming IO from dm. Would it be ok to call this from a target? In 
general is it going to be better to throttle incoming IO while failed 
bios are resubmitted?

I have attached a patch (built against 2.6.2-udm1) that begins to 
implement this. It does not provide the priority group callouts and it 
is untested and really only meant to show what I mean. Is this direction 
OK, or what is the intended purpose of the test IO+nr_test_paths code?

I also replaced the dm-daemon usage for a workqueue. It will allow us to 
do requeueing for different devices in parallel, and it attempts to 
execute the work on the same processor as it was queued.

Mike

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: failover.patch
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20040211/b5b6cdaa/attachment.ksh>


More information about the dm-devel mailing list