[dm-devel] 2.6.10-rc1-udm1: multipath work in progress

[Stefan Bader]

> ...
> So what else ought to be changed before freezing the interfaces?
> [One change I intend to make is  struct path  to  void  in dm-hw-handler.h
> and dm-path-selector.h]
> ...

I think for dm-path-selector.h this would be a step into the wrong 
direction.
Personally I would rather see path information moving into the path 
selector
domain. There are even some fields and functions in dm-mpath.c 
(current_count)
that are rather specific to a selector. Most of the functions in mpath.c 
do
not really need more than a path link (except some that implement generic 
selector
functionality like for example fail_path). On the other hand 
path-selectors
currently store the path pointer wrapped into their own structs for all 
paths and
often have to search this list to match a passed path pointer).
My proposal would be something like this:

Files:
        dm-path-selector.h      Definitions of core functions.
        dm-path-selector.c      Core functionality for path selectors.
        dm-path-selector-int.h  Defines common internal for path 
selectors.
        dm-path-selector-rr.c   The round-robin selector.

In mpath.c only the current_path_group is kept. It will always call 
ps->ps->select_path
(it still would have to get the bdev either by passing an pointer to 
select_path or
put a bdev_from_path to dm-path-selector.c). The constructor for 
path-selectors would
parse the paths and do the setup. The io functions would only use the path 
as a void
pointer to call path-selector functions.
Does this sound acceptable?

> New table example:
>   0 96000 multipath 
>   1 queue_if_no_path 0 1 round-robin 2 1 7:1 1 7:2 1

For path selectors: what about per selector arguments?

<selector-type> <nr of selector args> [<selector args>]*
        <nr of paths> (<nr of path args> [<path args>]* <path>)*

For example the round-robin could take the number of io operations
before switching to the next path:

round-robin 1 1000 2 1 7:1 1 7:2

/Stefan Bader