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

[Alasdair G Kergon]

On Wed, Nov 03, 2004 at 04:54:48PM +0100, Stefan Bader wrote:
> > We need some concrete examples of what information is missing and
> > how other sorts of path selectors would benefit from it.
 
> What doesn't work: a selector cannot parse its own arguments. 

Yes - there's a FIXME to extend that, but I'm waiting for
examples of such arguments: no point adding the facility 
until we're sure something will need to use it.
So far I have no concrete examples of anything needing it.

> I think it is only needed because path group layer and selector
> layer are mixed.

The current model puts generic path selection code
in dm-mpath.c.  The path selection modules only contain
the different algorithms used to choose a path.

I'm trying exporting a new 'struct path' to ps & hwh with
space for them to add their own state information.
  struct dm_dev *dev; // Not allowed to change this 
  void *pscontext;
  void *hwhcontext;
[patches on laptop which I can't connect today]

> I don't would it help to provide an example patch?

Most useful thing at present would be discussion of examples of 
realistic alternative classes of path selection algorithms so 
we can check how they fit into the framework.

The two considered so far are round-robin (already implemented)
and load-balancing (which I believe the current interface will
support adequately, possibly with the addition of the PS
arguments).

> But you would want to let the selector decide that and not the
> generic code. There might be selectors that want to send IOs to
> different paths based on other requirements. Ok, you can just set
> count to 0 then.

Or 1, meaning call the PS for every I/O.  
(Strongly discouraged, unless it's just to gather statistics - 
I'd expect a load balancer to want to vary this number each time.)

0 means don't call it again until the path has failed.
 
Alasdair
-- 
agk at redhat.com