Re: [dm-devel] pg failback

[christophe varoqui <christophe varoqui free fr>]

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 free fr>