From: Martin Wilck <martin.wilck@suse.com>
To: Christophe Varoqui <christophe.varoqui@opensvc.com>,
Benjamin Marzinski <bmarzins@redhat.com>
Cc: dm-devel@lists.linux.dev, linux-lvm@lists.linux.dev,
Zdenek Kabelac <zkabelac@redhat.com>,
Peter Rajnoha <prajnoha@redhat.com>
Subject: [PATCH 0/6] multipath-tools: udev rules and service improvements
Date: Mon, 5 Feb 2024 13:46:32 +0100 [thread overview]
Message-ID: <20240205124638.17877-1-mwilck@suse.com> (raw)
The first 3 patches and patch 5 are minor fixes for the udev rules.
Patch 4 fixes an issue that was observed in partner tests. Since we dropped
the dependency on systemd-udev-settle.service, it's more common that
multipath sees paths being added to existing maps during boot and reloads
the maps. If this happens while udev is executing rules for an uevent
related to the map in question (most importantly, a coldplug event),
the rules may see the map as suspended, and will refrain from scanning
the device content.
https://systemd.io/BLOCK_DEVICE_LOCKING/ doesn't help us here. We would need
to take an exclusive lock an lock_multipath() to achieve that, but since
5ec07b3 ("libmultipath: use a shared lock to co-operate with udev") we
don't. We _might_ consider re-introducing exclusive locking, because the main
reason we don't was that udev would discard events for which it couldn't
obtain the lock. Since systemd 250, udev has a retry logic for such events
which would avoid this problem. We would also need to implement similar retry
logic in multipathd, though. For now, and because we need to support systemd
< 250 anyway, I've come up with the workaround in patch 4 (first tests went
well, but more testing is still needed).
Patch 5 is a partial fix for the the problem that multipathd socket activation
starts multipathd also on systems that don't need it. See
https://github.com/opensvc/multipath-tools/issues/76. More far-reaching
approaches have been discussed to avoid that the user needs to enable
multipathd explicitly if multipath hardware is present
(https://github.com/opensvc/multipath-tools/pull/78) but no solid solution
for that has emerged yet.
Reviews and comments welcome.
Martin Wilck (6):
11-dm-mpath.rules: don't import properties that are already set
11-dm-mpath.rules: fix list of imported properties
11-dm-mpath.rules: use import logic like 13-dm-disk.rules
11-dm-mpath.rules: handle reloads during coldplug events
multipath: udev rules: use configured $(bindir) in udev rules
multipathd: don't activate socket activation by default
.gitignore | 1 +
Makefile.inc | 2 +-
...11-dm-mpath.rules => 11-dm-mpath.rules.in} | 49 ++++++++++++++-----
multipath/Makefile | 2 +-
multipath/multipath.rules.in | 5 +-
multipathd/multipathd.socket | 4 +-
6 files changed, 45 insertions(+), 18 deletions(-)
rename multipath/{11-dm-mpath.rules => 11-dm-mpath.rules.in} (73%)
--
2.43.0
next reply other threads:[~2024-02-05 12:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 12:46 Martin Wilck [this message]
2024-02-05 12:46 ` [PATCH 1/6] 11-dm-mpath.rules: don't import properties that are already set Martin Wilck
2024-02-05 20:44 ` Benjamin Marzinski
2024-02-06 10:50 ` Martin Wilck
2024-02-09 0:30 ` Benjamin Marzinski
2024-02-09 15:35 ` Martin Wilck
2024-02-05 12:46 ` [PATCH 2/6] 11-dm-mpath.rules: fix list of imported properties Martin Wilck
2024-02-09 0:32 ` Benjamin Marzinski
2024-02-05 12:46 ` [PATCH 3/6] 11-dm-mpath.rules: use import logic like 13-dm-disk.rules Martin Wilck
2024-02-09 0:36 ` Benjamin Marzinski
2024-02-09 15:38 ` Martin Wilck
2024-02-05 12:46 ` [PATCH 4/6] 11-dm-mpath.rules: handle reloads during coldplug events Martin Wilck
2024-02-09 1:03 ` Benjamin Marzinski
2024-02-09 15:53 ` Martin Wilck
2024-02-09 16:13 ` Benjamin Marzinski
2024-02-09 16:15 ` Benjamin Marzinski
2024-02-05 12:46 ` [PATCH 5/6] multipath: udev rules: use configured $(bindir) in udev rules Martin Wilck
2024-02-09 1:04 ` Benjamin Marzinski
2024-02-05 12:46 ` [PATCH 6/6] multipathd: don't activate socket activation by default Martin Wilck
2024-02-09 1:05 ` 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=20240205124638.17877-1-mwilck@suse.com \
--to=martin.wilck@suse.com \
--cc=bmarzins@redhat.com \
--cc=christophe.varoqui@opensvc.com \
--cc=dm-devel@lists.linux.dev \
--cc=linux-lvm@lists.linux.dev \
--cc=prajnoha@redhat.com \
--cc=zkabelac@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;
as well as URLs for NNTP newsgroup(s).