On lun, 2005-06-20 at 14:05 -0400, goggin, edward wrote: > Two things with path group failback seem flawed right now. > > (1) Looks like it might be possible for a currently disabled path group > which is not the highest priority path group to remain disabled even > when paths in the group test successfully. This seems to be possible > because the code in switch_pathgroup() called by checkerloop() in > multipathd only fails back to the highest priority path group. Granted > that the problem is primarily (__only__) cosmetic since the other group(s) > are not being actively used anyway, but it is still misleading to a viewer > of > "multipath -l" to see disabled path groups which should not be in this > state. > Yes, this one is on the todo. You already raised that point speaking of "kernel/userspace asymmetry" if I remember. > (2) Seems to me that currently disabled path groups should be enabled > before switching to one anyway. Doing so will enable the kernel code to > simply > reenable a group without initiating a pg_init of "a possibly newly > determined" > highest priority path group as is currently done. Instead, as a performance > Improvement over the way things are now, the multipathd code can reenable > path > groups as need be, and only initiate a switch path group when it determines > that this is necessary. > Some hardware (StorageWorks HSG, HSV1X0) need the unconditional pg_init as it is coded right now, so I guess we can't afford this little optimisation. Speaking of optimisation, have you witnessed too the ~20% performance decrease with multi-path PG ? Regards, -- christophe varoqui <christophe.varoqui@xxxxxxx>
