lvm2/SOURCES/0141-lvmlockd-vgchange-systemid-doen-t-need-global-lock.patch

43 lines
1.4 KiB
Diff

From 97aa5f67547f150b5f8f511249b200a41561a3c9 Mon Sep 17 00:00:00 2001
From: David Teigland <teigland@redhat.com>
Date: Thu, 27 Jun 2024 12:46:15 -0500
Subject: [PATCH 1/2] lvmlockd: vgchange systemid doen't need global lock
The comment explained that the ex global lock was just
used to trigger global cache invalidation, which is no
longer needed. This extra locking can cause problems
with LVM-activate when local and shared VGs are mixed
(and the incorrect exit code for errors was causing
problems.)
(cherry picked from commit 680f7bd676526771b7a26e35105af3bccb95e4a1)
---
tools/vgchange.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/tools/vgchange.c b/tools/vgchange.c
index e4b57dbd2..b0e2b2d2a 100644
--- a/tools/vgchange.c
+++ b/tools/vgchange.c
@@ -1231,17 +1231,6 @@ int vgchange_systemid_cmd(struct cmd_context *cmd, int argc, char **argv)
struct processing_handle *handle;
int ret;
- /*
- * This is a special case where taking the global lock is
- * not needed to protect global state, because the change is
- * only to an existing VG. But, taking the global lock ex is
- * helpful in this case to trigger a global cache validation
- * on other hosts, to cause them to see the new system_id or
- * lock_type.
- */
- if (!lockd_global(cmd, "ex"))
- return 0;
-
if (!(handle = init_processing_handle(cmd, NULL))) {
log_error("Failed to initialize processing handle.");
return ECMD_FAILED;
--
2.49.0