On Fri, Jun 02, 2023 at 06:16:08PM +0200, Martin Wilck wrote: > 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. There are no builtin device configs that set path grouping policy to FAILOVER. Out of all our builtin configs, the only SCSI one that doesn't specifically set the path grouping policy is the IBM 3303 NVDISK and I don't believe that one supports ALUA. I don't know of any vendor who wants to have a builtin device config for their array, but can't write an optimal one because they need a different pgpolicy depending on whether ALUA is or isn't present. So all I was saying is that I don't think having detect_pgplicy would enable us to add new builtin configs for arrays that we couldn't handle correctly in all cases before. I do agree that there are likely people who don't bother to edit multipath.conf for their device, and multipath autodetects alua but still uses FAILOVER, when it would be better for it to use GROUP_BY_PRIO. That's why I think your proposal is a good one. > > 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? > 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
