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
