From 97aa5f67547f150b5f8f511249b200a41561a3c9 Mon Sep 17 00:00:00 2001 From: David Teigland 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