Re: [PATCH 18/21] libmultipath: keep bindings in memory

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

 



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.

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.
> 

--
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