From 680f7bd676526771b7a26e35105af3bccb95e4a1 Mon Sep 17 00:00:00 2001 From: David Teigland Date: Thu, 27 Jun 2024 12:46:15 -0500 Subject: [PATCH] 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.) --- tools/vgchange.c | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/tools/vgchange.c b/tools/vgchange.c index 5eba2a1b3..8c57d065e 100644 --- a/tools/vgchange.c +++ b/tools/vgchange.c @@ -1533,17 +1533,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;