Re: [PATCH 5/5] libmultipath: add "detect_pgpolicy" config option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2023-06-01 at 13:17 -0500, Benjamin Marzinski wrote:
> On Wed, May 31, 2023 at 03:44:58PM +0000, Martin Wilck wrote:
> > On Fri, 2023-05-19 at 18:02 -0500, Benjamin Marzinski wrote:
> > > This allows configuations to use "group_by_tpg" if alua is
> > > autodetected
> > > and another policy if it isn't, so they can work with
> > > detect_prio.
> > 
> > This is a bit confusing. We might have introduced this kind of
> > autodetection without group_by_tpg; using group_by_prio for arrays
> > with
> > ALUA support would have made quite a bit of sense.
> 
> I guess that all depends on what the autodetection is for.  If the
> goal
> for ALUA autodetection is to make it possible to write configs that
> support arrays which have an optional ALUA mode, then I don't think
> this
> is necessary.  All those arrays should be configured with
> group_by_prio,
> regardless of whether or not they are in ALUA mode.

Hm, but are they, really? Xose has changed some defaults from multibus
to group_by_prio lately, but I am not sure if that covers all. If we
set group_by_prio automatically without ALUA, we'd probably end up
effectively with MULTIBUS always, as the prio would likely be constant.
But some arrays would prefer FAILOVER, I suppose, perhaps even some of
those with optional ALUA? I am not sure. But this is what really
matters: whether the array should work in active-active or active-
passive mode when there is no ALUA to detect it.

> But we've moved more towards adding autodetection to make multipath
> work
> correctly, even without a config for a specific array. In this case,
> yes, if we autodetect ALUA, if would be nice if we could
> automatically set group_by_prio.
> 
> > What this patch really does is to make multipath-tools prefer
> > group_by_tpg over group_by_prio if it finds that ALUA is
> > supported. 
> > Should this be a separate option, perhaps?
> > 
> >  - detect_pgpolicy: use an ALUA-based pgpolicy if available
> >  - detect_pgpolicy_prefer_tpg: prefer group_by_tpg over
> > group_by_prio
> >    for arrays supporting ALUA.
> > 
> > This way users could benefit from ALUA autodetection without
> > switching
> > to the TPG algorithm automatically.
> 
> Sure. Lets go with that. I'll respin this.

Perhaps you can come up with a better name than
"detect_pgpolicy_prefer_tpg" :-)

To make sure we're on the same boat:

 - detect_pgpolicy defaults to ON
 - detect_pgpolicy_prefer_tpg defaults to OFF for now.

Right?

> > Or do we have good arguments that group_by_tpg is always "better"
> > than
> > group_by_prio if ALUA is supported? I guess it might be, but it
> > still
> > needs to prove its usefulness it practice.
> 
> I would also rather it proved itself first. That's why I had it
> disabled
> by default. We can always switch the default later.
> 
> > Also, if we add the auto-detection feature, I think it should
> > default
> > to ON, at least upstream.
> 
> I don't know of any case where you would need FAILOVER, when you have
> an
> ALUA device.  I can imagine someone wanting to be able to turn off
> load-balancing, but I think it makes sense to enable this by default
> upstream.

I expect that active-passive arrays would use STANDBY state for the
passive side, or at least NON-OPTIMIZED. This would effectively be a
failover mode. Anyway, it'll be possible to deactivate the
autodetection. That's kind of awkward for users, as we now from
detect_checker etc., but it works, and fits the way we did this for
other options.

Regards
Martin

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel





[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux