[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