[dm-devel] [PATCH RFC 0/5] add support for manual failover devices

[Mike Christie]

Hi Joe,

Sorry that you will get these twice (especially considering it is
so long). Mails from my cs.wisc.edu account do not arrive on dm-devel
for a couple of days sometimes.

I am working on adding support for IBM's fastt which has a
failover mode that requires a failover command be sent before a
group of paths can be used. The following patches implement the
basic support needed from dm.

01-ps-failpath.patch - move the path failure decision to the path
selector. Some ps's may want to select paths that have a couple
failures over one that has N failures. If a ps has to track this info
there didn't seem to be a compelling reason to also do it in
dm-mpath.c. Well code duplication and sharing is a good reason to do
it in dm-mpath. It would be nice if I could just add an init function
to any ps and leach off other people's work :) but is that too modular?

Additionally, if a ps fails to activate a path or cannot use it
during initialization it may want to fail it.

02-export-ps-register-fns.patch - exports the register and
unregister ps functions.

03-ps-init.patch - makes priority group / path-selector
initialization possible. Remapping failed bios from end_io was not
nice becuase you couldn't choose a path until you knew a
group was activated and what paths in that group were still functional.
Plus, incoming IO needed to be mapped while failures were coming in.

I guess you could just make map_io sleep or do some internal queueing.
I choose the former, so I had to move the remap map_io call to
dispatch_failed_ios and add a get_mapinfo accessor function.

I think queueing incoming io while you finish the failed may be better,
but targets calling dm's queueing mechanism didn't seem right, and
reimplementing it didn't either. Well, I do not know if it is better
or not. While paths are failing performance is going to take a hit
so io ordering may only be a problem if you are concerned with
journaling or barrier type stuff (but as we end up sending IO down
multiple queues we cannot gaurantee ordering on the normal IO code
path anyways).

04-path-to-dev.patch - adds another accessor so path-selectors can
access a path's bdev. This is necessary for devices which need to
send commands down to the device. (see rdac-test-support.patch)

05-mpath-wq.patch - dispatch_failed_ios can sleep. It should not
disrupt other users of the default work queue. Under heavy load
or group/ps initializations on a single processor machine, this
conflict becomes painful.

complete-all.patch - the patches are against linux-2.6.5-rc1 udm1
which doesn't have complete_all exported. Newer mm versions do.

rdac-test-support.patch - this is just an example of what needs to
could be done by the ps to send a failover command to the device. This
example is just sending a TUR, and I just bascially ripped off the
rr ps's other functions. The point is that I have to inject a command
into a queue using blk_execute_rq or elv_add_request.

Mike