Linux Device Mapper development
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
Cc: dm-devel@redhat.com
Subject: Re: [dm-devel] [PATCH 18/21] libmultipath: keep bindings in memory
Date: Mon, 11 Sep 2023 08:25:05 +0200	[thread overview]
Message-ID: <3bfcf097c6c1f770da4ba0d80d2a06a2d131fd79.camel@suse.com> (raw)
In-Reply-To: <20230908172215.GI7412@octiron.msp.redhat.com>

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@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


  reply	other threads:[~2023-09-11  6:25 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-01 18:02 [dm-devel] [PATCH 00/21] multipath-tools: user-friendly names rework mwilck
2023-09-01 18:02 ` [dm-devel] [PATCH 01/21] libmultipath: sysfs_set_scsi_tmo: do nothing for ACT_DRY_RUN mwilck
2023-09-06 22:42   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 02/21] libmultipath: add alias_already_taken() mwilck
2023-09-06 22:42   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 03/21] libmultipath: unify use_existing_alias() and get_user_friendly_alias() mwilck
2023-09-06 22:42   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 04/21] libmultipath: never allocate an alias that's already taken mwilck
2023-09-06 22:42   ` Benjamin Marzinski
2023-09-07  7:24     ` Martin Wilck
2023-09-07 13:33       ` Martin Wilck
2023-09-07 14:22         ` Martin Wilck
2023-09-01 18:02 ` [dm-devel] [PATCH 05/21] libmultipath: lookup_binding: add comment about the algorithm mwilck
2023-09-06 22:43   ` Benjamin Marzinski
2023-09-07  8:22     ` Martin Wilck
2023-09-01 18:02 ` [dm-devel] [PATCH 06/21] multipath-tools test: simplify debugging for condlog mismatch mwilck
2023-09-06 22:43   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 07/21] multipath-tools tests: add tests for get_user_friendly_alias() mwilck
2023-09-06 22:43   ` Benjamin Marzinski
2023-09-07  7:55     ` Martin Wilck
2023-09-01 18:02 ` [dm-devel] [PATCH 08/21] multipath-tools test: consistent use of macros in alias test mwilck
2023-09-06 22:43   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 09/21] multipath-tools tests: convert mock_{failed, used}_alias to macros mwilck
2023-09-06 22:44   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 10/21] multipath-tools test: use mock_bindings_file() consistently mwilck
2023-09-06 22:43   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 11/21] libmultipath: add global variable for current bindings mwilck
2023-09-06 22:44   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 12/21] libmultipath: rename fix_bindings_file() to update_bindings_file() mwilck
2023-09-06 22:44   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 13/21] libmultipath: alias.c: move bindings related code up mwilck
2023-09-06 22:44   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 14/21] libmultipath: update_bindings_file: take filename argument mwilck
2023-09-06 22:45   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 15/21] libmultipath: update_bindings_file: use a single write() mwilck
2023-09-06 22:45   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 16/21] libmultipath: update_bindings_file: don't log temp file name mwilck
2023-09-06 22:45   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 17/21] libmultipath: alias.c: factor out read_binding() mwilck
2023-09-06 22:45   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 18/21] libmultipath: keep bindings in memory mwilck
2023-09-06 22:47   ` Benjamin Marzinski
2023-09-07 10:30     ` Martin Wilck
2023-09-07 19:14       ` Benjamin Marzinski
2023-09-07 20:02         ` Benjamin Marzinski
2023-09-07 20:43           ` Martin Wilck
2023-09-08 17:22             ` Benjamin Marzinski
2023-09-11  6:25               ` Martin Wilck [this message]
2023-09-11 14:47                 ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 19/21] multipath-tools tests: fix alias tests mwilck
2023-09-06 22:47   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 20/21] libmultipath: dm_get_uuid(): return emtpy UUID for non-existing maps mwilck
2023-09-06 22:47   ` Benjamin Marzinski
2023-09-01 18:02 ` [dm-devel] [PATCH 21/21] libmultipath: adapt to new semantics of dm_get_uuid() mwilck
2023-09-06 22:47   ` Benjamin Marzinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3bfcf097c6c1f770da4ba0d80d2a06a2d131fd79.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox