On 2004-11-08T17:01:01, christophe.varoqui@xxxxxxx wrote: > > 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. No. The mechanism you describe allows the path-prioritizer to influence the order of the priority groups, yes. But the in-kernel scheme discussed here allows a PG to be active w/o being the one in the front. > 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. That's the right direction, but not all the way, I think. The priority of the group is not the same thing as whether it's active or not. I think an additional call-out to query for the active or bypassed status for the PG is needed. Sincerely, Lars Marowsky-Brée <lmb@xxxxxxx> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business