[dm-devel] [PATCH 10/16] libmultipath: make pgpolicyfn take a paths vector

[Martin Wilck]

On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> To enable future changes, mp->pgpolicyfn() now takes a vector of
> paths instead of always using mp->paths.
> 
> Signed-off-by: Benjamin Marzinski <bmarzins at redhat.com>
> ---
>  libmultipath/pgpolicies.c | 38 +++++++++++++++++++----------------
> ---
>  libmultipath/pgpolicies.h | 10 +++++-----
>  libmultipath/structs.h    |  2 +-
>  3 files changed, 25 insertions(+), 25 deletions(-)
> 

The following applies to this patch and its successors (11-13, 15).

This is technically correct, beautiful code, but I'm not sure if this
is where we want to go. Do we really need that strict separation
between "normal" and "marginal" path groups?

As I already noted in my reply to 14/16, I'd favor an approach where
we would factor in the "marginality" of a path when calculating the
priority and the grouping. For example, when working with ALUA and
group_by_prio, rather than lumping all marginal paths together, we may
want to group like this:

 - active/optimized, healthy
 - active/non-optimized, healthy
 - active/optimized, marginal
 - active/non-optimized, marginal
 - standby
 - other

The priorities of these groups would be up to discussion. Today I'm not
even sure if "marginal" property should take precedence over
"optimized" property, or vice-versa. It might actually depend on the
situation and the degree of "shakiness" ...

OK: This is future material. But if we take this patch and its
successors, be'd have it cast in stone that "marginal/normal" is the
main distinction, taking precedence over everything else, and I'm not
convinced that that's the way to go.

We could obtain the semantics of your current patch set by assigning a
negative prio bias to marginal paths, and changing the grouping
algorithms (except group_by_prio) such that they take the marginal
property into account (e.g. group_by_node_name would pretend that all
marginal paths have a common "node name" and lump them together). This
would allow us to keep our current simple mpp->pg vector and represent
the marginal paths simply by one (the last) PG in this vector. 

The benefit would be that this model would be more flexible for more
sophisticated priority models in the future.

Regards,
Martin