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@xxxxxxxxxx