[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] 2.6.10-rc1-udm1: multipath work in progress
- From: christophe varoqui free fr
- To: device-mapper development <dm-devel redhat com>, Lars Marowsky-Bree <lmb suse de>
- Cc: device-mapper development <dm-devel redhat com>
- Subject: Re: [dm-devel] 2.6.10-rc1-udm1: multipath work in progress
- Date: Mon, 8 Nov 2004 17:01:01 +0100
Selon Lars Marowsky-Bree <lmb suse de>:
> On 2004-11-08T14:10:10, christophe varoqui free fr wrote:
>
> > > Christophe, any particular wishes on how to implement this in the
> > > multipath-tools? Would you want an additional helper to call to
> > > answer the question of which PG should be active or bypassed first?
> > >
> > I guess you lost me one more time, as I thought the response to this
> > particular question was under userspace responsability.
> >
>
> Yes, that's why I asked how you'd want to implement it in the
> multipath-tools. /sbin/multipath must find out somehow which PG to
> activate first, right?
>
Right : it already does.
The logic is based on the priority framework.
You can plug-in path-prioritizer callouts.
Default path prio is 1 for a valid path, 0 for a failing path.
So by default the pg with most active paths wins.
I also took a pick at a prioritizer that brings into the equation the number of
LU in control of a controler, so that it can balance the LU across all
controlers available.
I guess you can alter the pg priorities the way anyone can imagine based on that
framework. With the current kernel driver, PG are fed in params strings in
top-down summed-path-priority order.
Feeding those priority numbers directly into the params strings and keep the PG
statically ordered shouldn't be too invasive a change.
regards,
cvaroqui
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]