[dm-devel] [PATCH 18/21] libmultipath: keep bindings in memory

[Benjamin Marzinski]

On Mon, Sep 11, 2023 at 08:25:05AM +0200, Martin Wilck wrote:
> On Fri, 2023-09-08 at 12:22 -0500, Benjamin Marzinski wrote:
> > On Thu, Sep 07, 2023 at 10:43:27PM +0200, Martin Wilck wrote: 
> > > Our bindings list is now partially sorted, which is an improvement
> > > wrt
> > > the previous situation. "missing the gap" is not really an awful
> > > problem [*]. Perhaps we could postpone this for after this patch
> > > set,
> > > and give it some more time to sink in?
> > 
> > Yep. I'm fine with going ahead with this patchset as it is. Both
> > sorting
> > the bindings in alias order and updating the bindings if
> > /etc/multipath/bindings has changed are things that can get looked at
> > afterwards. And I'm fine with doing this work, if you want.
> 
> It so happens that, by sudden inspiration, I've found an elegant
> solution to this problem (I think). We can take advantage of the fact
> that, for any given prefix, aliases with shorter string length will be
> sorted before longer ones ("mpathz" < "mpathaa"). By sorting the
> aliases by string length, and use alphabetical sorting only for strings
> of equal length, we obtain total ordering for any given prefix. This
> works for any number of different prefixes, and even if some prefixes
> are substrings of others. In the ordered list, the aliases with a given
> prefix will not necessarily be in a contiguous block, but that doesn't
> matter. For every prefix, the sub-list of aliases starting with that
> prefix is cleanly ordered. This way we avoid the complexity to have to
> parse or compare configured prefixes.

Clever. That seems like a good solution.

-Ben 

> 
> I'll post a new patch set with this ordering scheme hopefully later
> today.
> 
> Regards,
> Martin
> 
> > 
> > -Ben
> >  
> > > Martin
> > > 
> > > [*] I admit that with my patch, we _know_ now that the bindings
> > > list
> > > will be sub-optimally sorted as soon as mpathaa is reached, whereas
> > > before the ordering might be perfect even with a large number of
> > > aliases, depending on the history of the bindings file. That's not
> > > a
> > > change for the better; it will cause the gap to be missed in some
> > > situations where we don't miss it now. I am not sure how bad this
> > > is.
> >