shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Code Releases Activity
0bdd6d6240
lvm2/tools/vgrename.c

247 lines
7.0 KiB
C
Raw Normal View History

vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
/*
Some whitespace tidy-ups.
2008-01-30 17:00:02 +03:00
* Copyright (C) 2001-2004 Sistina Software, Inc. All rights reserved.
Refactor vgrename into vg_rename_old and vg_rename_new. Should be no functional change. Will allow us to reorder lock obtaining if needed. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:29:23 +04:00
* Copyright (C) 2004-2009 Red Hat, Inc. All rights reserved.
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* This file is part of LVM2.
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* This copyrighted material is made available to anyone wishing to use,
* modify, copy, or redistribute it subject to the terms and conditions
Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.
2007-08-21 00:55:30 +04:00
* of the GNU Lesser General Public License v.2.1.
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
*
Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.
2007-08-21 00:55:30 +04:00
* You should have received a copy of the GNU Lesser General Public License
Update copyright notices.
2004-03-30 23:35:44 +04:00
* along with this program; if not, write to the Free Software Foundation,
doc: change fsf address Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
2016-01-21 13:49:46 +03:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
*/
#include "tools.h"
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
struct vgrename_params {
const char *vg_name_old;
const char *vg_name_new;
unsigned int old_name_is_uuid : 1;
unsigned int lock_vg_old_first : 1;
unsigned int unlock_new_name: 1;
};
Refactor vgrename into vg_rename_old and vg_rename_new. Should be no functional change. Will allow us to reorder lock obtaining if needed. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:29:23 +04:00
Allow VGs with active LVs to be renamed.
2010-04-14 17:03:06 +04:00
static int _lock_new_vg_for_rename(struct cmd_context *cmd,
const char *vg_name_new)
Refactor vgrename into vg_rename_old and vg_rename_new. Should be no functional change. Will allow us to reorder lock obtaining if needed. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:29:23 +04:00
{
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
if (!lock_vol(cmd, vg_name_new, LCK_VG_WRITE, NULL)) {
Refactor vgrename into vg_rename_old and vg_rename_new. Should be no functional change. Will allow us to reorder lock obtaining if needed. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:29:23 +04:00
log_error("Can't get lock for %s", vg_name_new);
return 0;
}
return 1;
}
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
static int _vgrename_single(struct cmd_context *cmd, const char *vg_name,
struct volume_group *vg, struct processing_handle *handle)
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
{
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
struct vgrename_params *vp = (struct vgrename_params *) handle->custom_handle;
vgrename: use long enough buffer for path Use PATH_MAX when creating buffers for rename.
2017-03-30 01:17:37 +03:00
char old_path[PATH_MAX];
char new_path[PATH_MAX];
vgrename accepts vgid and exported VG.
2006-04-14 01:08:29 +04:00
struct id id;
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
const char *name;
char *dev_dir;
vgrename: run fullscan For vgrename run full scan so the command is able to properly detect name collision.
2013-10-08 13:15:05 +04:00
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
/*
* vg_name_old may be a UUID which process_each_vg
* replaced with the real VG name. In that case,
* vp->vg_name_old will be the UUID and vg_name will be
* the actual VG name. Check again if the old and new
* names match, using the real names.
*/
if (vp->old_name_is_uuid && !strcmp(vp->vg_name_new, vg_name)) {
log_error("New VG name must differ from the old VG name.");
return ECMD_FAILED;
Run through indent - no (intentional) changes to any code.
2002-02-12 00:00:35 +03:00
}
o Support locking with local lock files o Disable control-c during updates (except if blocked waiting for a lock)
2002-02-11 18:42:34 +03:00
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
/*
* Check if a VG already exists with the new VG name.
*
* (FIXME: We could look for the new name in the list of all
* VGs that process_each_vg created, but we don't have access
Remove lvmetad Native disk scanning is now both reduced and async/parallel, which makes it comparable in performance (and often faster) when compared to lvm using lvmetad. Autoactivation now uses local temp files to record online PVs, and no longer requires lvmetad. There should be no apparent command-level change in behavior.
2018-07-10 21:39:29 +03:00
* to that list here, so we have to look in lvmcache.)
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
*/
coverity: drop unused assignments
2016-02-23 21:57:56 +03:00
if (lvmcache_vginfo_from_vgname(vp->vg_name_new, NULL)) {
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
log_error("New VG name \"%s\" already exists", vp->vg_name_new);
return ECMD_FAILED;
vgrename accepts vgid and exported VG.
2006-04-14 01:08:29 +04:00
}
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
if (id_read_format_try(&id, vp->vg_name_new) &&
(name = lvmcache_vgname_from_vgid(cmd->mem, (const char *)&id))) {
log_error("New VG name \"%s\" matches the UUID of existing VG %s", vp->vg_name_new, name);
return ECMD_FAILED;
}
Update vgrename to take into account vgname lock ordering. Should be no functional change. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:29:40 +04:00
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
/*
* Lock the old VG name first:
* . The old VG name has already been locked by process_each_vg.
* . Now lock the new VG name here, second.
*
* Lock the new VG name first:
* . The new VG name has already been pre-locked below,
* before process_each_vg was called.
* . process_each_vg then locked the old VG name second.
* . Nothing to do here.
*
* Special case when the old VG name is a uuid:
* . The old VG's real name wasn't known before process_each_vg,
* so the correct lock ordering wasn't known beforehand,
* so no pre-locking was done.
* . The old VG's real name has been locked by process_each_vg.
* . Now lock the new VG name here, second.
* . Suppress lock ordering checks because the lock order may
* have wanted the new name first, which wasn't possible in
* this uuid-for-name case.
*/
if (vp->lock_vg_old_first || vp->old_name_is_uuid) {
if (!_lock_new_vg_for_rename(cmd, vp->vg_name_new))
return ECMD_FAILED;
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
}
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
dev_dir = cmd->dev_dir;
cache dropping needs to use old name not new rename variable to reduce confusion
2008-06-06 20:13:35 +04:00
if (!archive(vg))
o Support locking with local lock files o Disable control-c during updates (except if blocked waiting for a lock)
2002-02-11 18:42:34 +03:00
goto error;
Add archiving.
2002-01-09 16:17:14 +03:00
vgrename: add missing trace on error path
2015-09-03 18:38:16 +03:00
if (!lockd_rename_vg_before(cmd, vg)) {
stack;
lockd: vgrename fixes If busy locks in lvmlockd prevent vgrename, use the correct error exit path, and print a user-friendly error message.
2015-09-03 18:21:44 +03:00
goto error;
vgrename: add missing trace on error path
2015-09-03 18:38:16 +03:00
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
vgrename & vgck
2001-10-08 22:44:22 +04:00
/* Change the volume group name */
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
vg_rename(cmd, vg, vp->vg_name_new);
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
Fix vgrename using UUID in case there are VGs with the same name.
2008-12-19 17:22:48 +03:00
/* store it on disks */
log_verbose("Writing out updated volume group");
if (!vg_write(vg) || !vg_commit(vg)) {
goto error;
}
vgrename: use long enough buffer for path Use PATH_MAX when creating buffers for rename.
2017-03-30 01:17:37 +03:00
if ((dm_snprintf(old_path, sizeof(old_path), "%s%s", dev_dir, vg_name) < 0) ||
(dm_snprintf(new_path, sizeof(new_path), "%s%s", dev_dir, vp->vg_name_new) < 0)) {
log_error("Renaming path is too long %s/%s %s/%s",
dev_dir, vg_name, dev_dir, vp->vg_name_new);
goto error;
}
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
Don't touch /dev in vgrename if activation is disabled.
2008-04-30 18:34:02 +04:00
if (activation() && dir_exists(old_path)) {
o Support locking with local lock files o Disable control-c during updates (except if blocked waiting for a lock)
2002-02-11 18:42:34 +03:00
log_verbose("Renaming \"%s\" to \"%s\"", old_path, new_path);
Fix vgrename using UUID in case there are VGs with the same name.
2008-12-19 17:22:48 +03:00
Some new features.
2002-11-18 17:04:08 +03:00
if (test_mode())
log_verbose("Test mode: Skipping rename.");
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
Remove lvs_in_vg_activated_by_uuid_only call. There is no difference from lvs_in_vg_activated now, convert all users to this call.
2010-02-24 23:01:40 +03:00
else if (lvs_in_vg_activated(vg)) {
Add "--refresh" functionality to vgchange and vgmknodes.
2008-12-22 12:00:51 +03:00
if (!vg_refresh_visible(cmd, vg)) {
Fix vgrename using UUID in case there are VGs with the same name.
2008-12-19 17:22:48 +03:00
log_error("Renaming \"%s\" to \"%s\" failed",
old_path, new_path);
goto error;
}
}
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
lockd_rename_vg_final(cmd, vg, 1);
Add backtraces for backup and backup_remove fail paths
2010-12-22 18:36:41 +03:00
if (!backup(vg))
stack;
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
if (!backup_remove(cmd, vg_name))
Add backtraces for backup and backup_remove fail paths
2010-12-22 18:36:41 +03:00
stack;
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
lvmetad: two phase vg_update Previously, a command sent lvmetad new VG metadata in vg_commit(). In vg_commit(), devices are suspended, so any memory allocation done by the command while sending to lvmetad, or by lvmetad while updating its cache could deadlock if memory reclaim was triggered. Now lvmetad is updated in unlock_vg(), after devices are resumed. The new method for updating VG metadata in lvmetad is in two phases: 1. In vg_write(), before devices are suspended, the command sends lvmetad a short message ("set_vg_info") telling it what the new VG seqno will be. lvmetad sees that the seqno is newer than the seqno of its cached VG, so it sets the INVALID flag for the cached VG. If sending the message to lvmetad fails, the command fails before the metadata is committed and the change is not made. If sending the message succeeds, vg_commit() is called. 2. In unlock_vg(), after devices are resumed, the command sends lvmetad the standard vg_update message with the new metadata. lvmetad sees that the seqno in the new metadata matches the seqno it saved from set_vg_info, and knows it has the latest copy, so it clears the INVALID flag for the cached VG. If a command fails between 1 and 2 (after committing the VG on disk, but before sending lvmetad the new metadata), the cached VG retains the INVALID flag in lvmetad. A subsequent command will read the cached VG from lvmetad, see the INVALID flag, ignore the cached copy, read the VG from disk instead, update the lvmetad copy with the latest copy from disk, (this clears the INVALID flag in lvmetad), and use the correct VG metadata for the command. (This INVALID mechanism already existed for use by lvmlockd.)
2016-06-08 22:42:03 +03:00
unlock_vg(cmd, vg, vp->vg_name_new);
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
vp->unlock_new_name = 0;
o Support locking with local lock files o Disable control-c during updates (except if blocked waiting for a lock)
2002-02-11 18:42:34 +03:00
config: add silent mode Accept -q as the short form of --quiet. Suppress non-essential standard output if -q is given twice. Treat log/silent in lvm.conf as equivalent to -qq. Review all log_print messages and change some to log_print_unless_silent. When silent, the following commands still produce output: dumpconfig, lvdisplay, lvmdiskscan, lvs, pvck, pvdisplay, pvs, version, vgcfgrestore -l, vgdisplay, vgs. [Needs checking.] Non-essential messages are shifted from log level 4 to log level 5 for syslog and lvm2_log_fn purposes.
2012-08-25 23:35:48 +04:00
log_print_unless_silent("Volume group \"%s\" successfully renamed to \"%s\"",
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
vp->vg_name_old, vp->vg_name_new);
prepare to move guts of vgrename into library function
2007-08-31 23:09:49 +04:00
return 1;
o Support locking with local lock files o Disable control-c during updates (except if blocked waiting for a lock)
2002-02-11 18:42:34 +03:00
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
error:
lvmetad: two phase vg_update Previously, a command sent lvmetad new VG metadata in vg_commit(). In vg_commit(), devices are suspended, so any memory allocation done by the command while sending to lvmetad, or by lvmetad while updating its cache could deadlock if memory reclaim was triggered. Now lvmetad is updated in unlock_vg(), after devices are resumed. The new method for updating VG metadata in lvmetad is in two phases: 1. In vg_write(), before devices are suspended, the command sends lvmetad a short message ("set_vg_info") telling it what the new VG seqno will be. lvmetad sees that the seqno is newer than the seqno of its cached VG, so it sets the INVALID flag for the cached VG. If sending the message to lvmetad fails, the command fails before the metadata is committed and the change is not made. If sending the message succeeds, vg_commit() is called. 2. In unlock_vg(), after devices are resumed, the command sends lvmetad the standard vg_update message with the new metadata. lvmetad sees that the seqno in the new metadata matches the seqno it saved from set_vg_info, and knows it has the latest copy, so it clears the INVALID flag for the cached VG. If a command fails between 1 and 2 (after committing the VG on disk, but before sending lvmetad the new metadata), the cached VG retains the INVALID flag in lvmetad. A subsequent command will read the cached VG from lvmetad, see the INVALID flag, ignore the cached copy, read the VG from disk instead, update the lvmetad copy with the latest copy from disk, (this clears the INVALID flag in lvmetad), and use the correct VG metadata for the command. (This INVALID mechanism already existed for use by lvmlockd.)
2016-06-08 22:42:03 +03:00
unlock_vg(cmd, vg, vp->vg_name_new);
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
vp->unlock_new_name = 0;
Add lvmlockd
2015-03-05 23:00:44 +03:00
lockd_rename_vg_final(cmd, vg, 0);
prepare to move guts of vgrename into library function
2007-08-31 23:09:49 +04:00
return 0;
}
int vgrename(struct cmd_context *cmd, int argc, char **argv)
{
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
struct vgrename_params vp = { 0 };
struct processing_handle *handle;
const char *vg_name_new;
const char *vg_name_old;
struct id id;
int ret;
prepare to move guts of vgrename into library function
2007-08-31 23:09:49 +04:00
if (argc != 2) {
log_error("Old and new volume group names need specifying");
return EINVALID_CMD_LINE;
}
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
vg_name_old = skip_dev_dir(cmd, argv[0], NULL);
vg_name_new = skip_dev_dir(cmd, argv[1], NULL);
if (!validate_vg_rename_params(cmd, vg_name_old, vg_name_new))
return_0;
if (!(vp.vg_name_old = dm_pool_strdup(cmd->mem, vg_name_old)))
return_ECMD_FAILED;
if (!(vp.vg_name_new = dm_pool_strdup(cmd->mem, vg_name_new)))
return_ECMD_FAILED;
locking: unify global lock for flock and lockd There have been two file locks used to protect lvm "global state": "ORPHANS" and "GLOBAL". Commands that used the ORPHAN flock in exclusive mode: pvcreate, pvremove, vgcreate, vgextend, vgremove, vgcfgrestore Commands that used the ORPHAN flock in shared mode: vgimportclone, pvs, pvscan, pvresize, pvmove, pvdisplay, pvchange, fullreport Commands that used the GLOBAL flock in exclusive mode: pvchange, pvscan, vgimportclone, vgscan Commands that used the GLOBAL flock in shared mode: pvscan --cache, pvs The ORPHAN lock covers the important cases of serializing the use of orphan PVs. It also partially covers the reporting of orphan PVs (although not correctly as explained below.) The GLOBAL lock doesn't seem to have a clear purpose (it may have eroded over time.) Neither lock correctly protects the VG namespace, or orphan PV properties. To simplify and correct these issues, the two separate flocks are combined into the one GLOBAL flock, and this flock is used from the locking sites that are in place for the lvmlockd global lock. The logic behind the lvmlockd (distributed) global lock is that any command that changes "global state" needs to take the global lock in ex mode. Global state in lvm is: the list of VG names, the set of orphan PVs, and any properties of orphan PVs. Reading this global state can use the global lock in sh mode to ensure it doesn't change while being reported. The locking of global state now looks like: lockd_global() previously named lockd_gl(), acquires the distributed global lock through lvmlockd. This is unchanged. It serializes distributed lvm commands that are changing global state. This is a no-op when lvmlockd is not in use. lockf_global() acquires an flock on a local file. It serializes local lvm commands that are changing global state. lock_global() first calls lockf_global() to acquire the local flock for global state, and if this succeeds, it calls lockd_global() to acquire the distributed lock for global state. Replace instances of lockd_gl() with lock_global(), so that the existing sites for lvmlockd global state locking are now also used for local file locking of global state. Remove the previous file locking calls lock_vol(GLOBAL) and lock_vol(ORPHAN). The following commands which change global state are now serialized with the exclusive global flock: pvchange (of orphan), pvresize (of orphan), pvcreate, pvremove, vgcreate, vgextend, vgremove, vgreduce, vgrename, vgcfgrestore, vgimportclone, vgmerge, vgsplit Commands that use a shared flock to read global state (and will be serialized against the prior list) are those that use process_each functions that are based on processing a list of all VG names, or all PVs. The list of all VGs or all PVs is global state and the shared lock prevents those lists from changing while the command is processing them. The ORPHAN lock previously attempted to produce an accurate listing of orphan PVs, but it was only acquired at the end of the command during the fake vg_read of the fake orphan vg. This is not when orphan PVs were determined; they were determined by elimination beforehand by processing all real VGs, and subtracting the PVs in the real VGs from the list of all PVs that had been identified during the initial scan. This is fixed by holding the single global lock in shared mode while processing all VGs to determine the list of orphan PVs.
2019-04-18 23:01:19 +03:00
if (!lock_global(cmd, "ex"))
Add lvmlockd
2015-03-05 23:00:44 +03:00
return_ECMD_FAILED;
add device hints to reduce scanning Save the list of PVs in /run/lvm/hints. These hints are used to reduce scanning in a number of commands to only the PVs on the system, or only the PVs in a requested VG (rather than all devices on the system.)
2018-12-07 23:35:22 +03:00
clear_hint_file(cmd);
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
/*
* Special case where vg_name_old may be a UUID:
* If vg_name_old is a UUID, then process_each may
* translate it to an actual VG name that we don't
* yet know. The lock ordering, and pre-locking,
* needs to be done based on VG names. When
* vg_name_old is a UUID, do not do any pre-locking
* based on it, since it's likely to be wrong, and
* defer all the locking to the _single function.
*
* When it's not a UUID, we know the two VG names,
* and we can pre-lock the new VG name if the lock
* ordering wants it locked before the old VG name
* which will be locked by process_each. If lock
* ordering wants the old name locked first, then
* the _single function will lock the new VG name.
*/
if (!(vp.old_name_is_uuid = id_read_format_try(&id, vg_name_old))) {
if (strcmp(vg_name_new, vg_name_old) < 0) {
vp.lock_vg_old_first = 0;
vp.unlock_new_name = 1;
if (!_lock_new_vg_for_rename(cmd, vg_name_new))
return ECMD_FAILED;
} else {
/* The old VG is locked by process_each_vg. */
vp.lock_vg_old_first = 1;
}
}
toollib: add 'parent' field to processing_handle; init report format only if there's no parent If there's parent processing handle, we don't need to create completely new report group and status report - we'll just reuse the one already initialized for the parent. Currently, the situation where this matter is when doing internal report to do the selection for processing commands where we have parent processing handle for the command itself and processing handle for the selection part (that is selection for non-reporting tools).
2016-05-31 13:24:05 +03:00
if (!(handle = init_processing_handle(cmd, NULL))) {
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
log_error("Failed to initialize processing handle.");
return ECMD_FAILED;
}
handle->custom_handle = &vp;
exported vg handling The exported VG checking/enforcement was scattered and inconsistent. This centralizes it and makes it consistent, following the existing approach for foreign and shared VGs/PVs, which are very similar to exported VGs/PVs. The access policy that now applies to foreign/shared/exported VGs/PVs, is that if a foreign/shared/exported VG/PV is named on the command line (i.e. explicitly requested by the user), and the command is not permitted to operate on it because it is foreign/shared/exported, then an access error is reported and the command exits with an error. But, if the command is processing all VGs/PVs, and happens to come across a foreign/shared/exported VG/PV (that is not explicitly named on the command line), then the command silently skips it and does not produce an error. A command using tags or --select handles inaccessible VGs/PVs the same way as a command processing all VGs/PVs, and will not report/return errors if these inaccessible VGs/PVs exist. The new policy fixes the exit codes on a somewhat random set of commands that previously exited with an error if they were looking at all VGs/PVs and an exported VG existed on the system. There should be no change to which commands are allowed/disallowed on exported VGs/PVs. Certain LV commands (lvs/lvdisplay/lvscan) would previously not display LVs from an exported VG (for unknown reasons). This has not changed. The lvm fullreport command would previously report info about an exported VG but not about the LVs in it. This has changed to include all info from the exported VG.
2019-06-21 21:37:11 +03:00
ret = process_each_vg(cmd, 0, NULL, vg_name_old, NULL, READ_FOR_UPDATE,
toollib: make it possible to also process internal VGs, add 'include_internal' switch to process_each_vg fn The lvm fullreport works per VG and as such, the vg, lv, pv, seg and pvseg subreport is done for each VG. However, if the PV is not part of any VG yet, we still want to display pv and pvseg subreports for these "orphan" PVs - so enable this for lvm fullreport's process_each_vg call.
2016-05-03 12:46:28 +03:00
0, handle, _vgrename_single);
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
/* Needed if process_each_vg returns error before calling _single. */
if (vp.unlock_new_name)
lvmetad: two phase vg_update Previously, a command sent lvmetad new VG metadata in vg_commit(). In vg_commit(), devices are suspended, so any memory allocation done by the command while sending to lvmetad, or by lvmetad while updating its cache could deadlock if memory reclaim was triggered. Now lvmetad is updated in unlock_vg(), after devices are resumed. The new method for updating VG metadata in lvmetad is in two phases: 1. In vg_write(), before devices are suspended, the command sends lvmetad a short message ("set_vg_info") telling it what the new VG seqno will be. lvmetad sees that the seqno is newer than the seqno of its cached VG, so it sets the INVALID flag for the cached VG. If sending the message to lvmetad fails, the command fails before the metadata is committed and the change is not made. If sending the message succeeds, vg_commit() is called. 2. In unlock_vg(), after devices are resumed, the command sends lvmetad the standard vg_update message with the new metadata. lvmetad sees that the seqno in the new metadata matches the seqno it saved from set_vg_info, and knows it has the latest copy, so it clears the INVALID flag for the cached VG. If a command fails between 1 and 2 (after committing the VG on disk, but before sending lvmetad the new metadata), the cached VG retains the INVALID flag in lvmetad. A subsequent command will read the cached VG from lvmetad, see the INVALID flag, ignore the cached copy, read the VG from disk instead, update the lvmetad copy with the latest copy from disk, (this clears the INVALID flag in lvmetad), and use the correct VG metadata for the command. (This INVALID mechanism already existed for use by lvmlockd.)
2016-06-08 22:42:03 +03:00
unlock_vg(cmd, NULL, vg_name_new);
Refactor vgrename into vg_rename_old and vg_rename_new. Should be no functional change. Will allow us to reorder lock obtaining if needed. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:29:23 +04:00
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
destroy_processing_handle(cmd, handle);
return ret;
vgrename & pvchange outlines
2001-10-03 21:03:25 +04:00
}
Copy Permalink