shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-21 13:34:40 +03:00
Code Releases Activity
55687b6656
lvm2/tools/toollib.c

6085 lines
166 KiB
C
Raw Normal View History

lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
/*
Some whitespace tidy-ups.
2008-01-30 17:00:02 +03:00
* Copyright (C) 2001-2004 Sistina Software, Inc. All rights reserved.
thin: add new ZERO/DISCARDS_UNSELECTED To more easily recognize unselected state from select '0' state add new 'THIN_ZERO_UNSELECTED' enum. Same applies to THIN_DISCARDS_UNSELECTED. For those we no longer need to use PASS_ARG_ZERO or PASS_ARG_DISCARDS.
2017-03-03 22:46:13 +03:00
* Copyright (C) 2004-2017 Red Hat, Inc. All rights reserved.
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* This file is part of LVM2.
*
* 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.
Update copyright notices.
2004-03-30 23:35:44 +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
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
*/
Sync include file changes.
2001-10-06 01:39:30 +04:00
#include "tools.h"
build: Don't generate symlinks in include/ dir As we start refactoring the code to break dependencies (see doc/refactoring.txt), I want us to use full paths in the includes (eg, #include "base/data-struct/list.h"). This makes it more obvious when we're breaking abstraction boundaries, eg, including a file in metadata/ from base/
2018-05-14 12:30:20 +03:00
#include "lib/format_text/format-text.h"
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
#include "lib/label/hints.h"
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
#include "lib/device/device_id.h"
move code from pvscan.c to online.c related to managing files in /run/lvm/pvs_online and /run/lvm/vgs_online
2021-11-04 00:02:38 +03:00
#include "lib/device/online.h"
lvremove: remove device_id for PVs on LVs When PVs are created on LVs, remove the devices file entries for the PVs when the LVs are removed. In general, the devices file entries should be removed with lvmdevices --deldev when the LVs are removed (lvremove is the equivalent of detaching a device from the system when layering PVs on LVs.) This change is effectively an automatic lvmdevices --deldev command that is built into lvremove when the LV has a PV on it.
2024-05-22 23:32:17 +03:00
#include "libdm/misc/dm-ioctl.h"
include: Standardise around new tool.h.
2015-07-06 19:30:18 +03:00
o Add autobackup support to tools (follows most vg_write calls). o Skip autobackup when in test mode. o Set test mode from config file. o Create system/backup dirs if not present (unless LVM_SYSTEM_DIR holds "").
2002-01-01 00:27:39 +03:00
#include <sys/stat.h>
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
#include <signal.h>
#include <sys/wait.h>
system_id: use for VG ownership See included lvmsystemid(7) for full description.
2014-10-24 21:29:04 +04:00
#include <sys/utsname.h>
cleanup: refactor common code Refactor shared code from _get_rootvg_dev() between vgchange and vgimportdevices to get_rootvg_dev_uuid() in toollib.c
2024-05-27 16:56:53 +03:00
#include <mntent.h>
o Add autobackup support to tools (follows most vg_write calls). o Skip autobackup when in test mode. o Set test mode from config file. o Create system/backup dirs if not present (unless LVM_SYSTEM_DIR holds "").
2002-01-01 00:27:39 +03:00
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
#define report_log_ret_code(ret_code) report_current_object_cmdlog(REPORT_OBJECT_CMDLOG_NAME, \
cleanup: add braces in macro
2017-07-19 17:17:30 +03:00
((ret_code) == ECMD_PROCESSED) ? REPORT_OBJECT_CMDLOG_SUCCESS \
: REPORT_OBJECT_CMDLOG_FAILURE, (ret_code))
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
Check for libsepol. Add some cflow & scope support. Separate out DEFS from CFLAGS. Remove inlines and use unique function names.
2006-04-19 19:33:07 +04:00
const char *command_name(struct cmd_context *cmd)
{
return cmd->command->name;
}
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
static void _sigchld_handler(int sig __attribute__((unused)))
{
while (wait4(-1, NULL, WNOHANG | WUNTRACED, NULL) > 0) ;
}
/*
* returns:
* -1 if the fork failed
* 0 if the parent
* 1 if the child
*/
int become_daemon(struct cmd_context *cmd, int skip_lvm)
{
cleanup: add static _
2024-05-13 01:04:28 +03:00
static const char _devnull[] = "/dev/null";
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
int null_fd;
pid_t pid;
struct sigaction act = {
make: fix compilation for some compiler Reported-by: adamboardman of gemian
2021-09-24 18:18:30 +03:00
.sa_handler = _sigchld_handler,
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
.sa_flags = SA_NOCLDSTOP,
};
toollib: Fix misleading message when forking. Commands like pvscan --background run entirely in the background, but others fork only for polling.
2016-04-14 19:21:02 +03:00
log_verbose("Forking background process from command: %s", cmd->cmd_line);
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
cov: warn about failing sigaction
2018-10-15 15:15:58 +03:00
if (sigaction(SIGCHLD, &act, NULL))
log_warn("WARNING: Failed to set SIGCHLD action.");
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
if (!skip_lvm)
locking: Add missing error handling. Add missing error logging and detection to unlock_vg and callers of sync_local_dev_names etc.
2015-06-30 20:54:38 +03:00
if (!sync_local_dev_names(cmd)) { /* Flush ops and reset dm cookie */
log_error("Failed to sync local devices before forking.");
return -1;
}
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
if ((pid = fork()) == -1) {
log_error("fork failed: %s", strerror(errno));
return -1;
}
/* Parent */
if (pid > 0)
return 0;
/* Child */
if (setsid() == -1)
log_error("Background process failed to setsid: %s",
strerror(errno));
toollib: tweak background forking Log what is forked and replace #if 1 with DEBUG_CHILD.
2013-09-06 04:49:43 +04:00
/* Set this to avoid discarding output from background process */
debug: Use // for commented out debug #defines The traditional style used for optional editable definitions /* #define X /* */ produces a bogus warning from gcc -Wall. Rather than suppressing this with -Wno-comment, switch over to the // comment style.
2013-09-16 23:20:26 +04:00
// #define DEBUG_CHILD
toollib: tweak background forking Log what is forked and replace #if 1 with DEBUG_CHILD.
2013-09-06 04:49:43 +04:00
#ifndef DEBUG_CHILD
cleanup: add static _
2024-05-13 01:04:28 +03:00
if ((null_fd = open(_devnull, O_RDWR)) == -1) {
log_sys_error("open", _devnull);
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
_exit(ECMD_FAILED);
}
cov: hide some false positives Hide some false positives. Note: there must not a be blank line after coverity hiding comment.
2023-05-10 14:01:37 +03:00
/* coverity[leaked_handle] don't care */
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
if ((dup2(null_fd, STDIN_FILENO) < 0) || /* reopen stdin */
(dup2(null_fd, STDOUT_FILENO) < 0) || /* reopen stdout */
(dup2(null_fd, STDERR_FILENO) < 0)) { /* reopen stderr */
log_sys_error("dup2", "redirect");
(void) close(null_fd);
_exit(ECMD_FAILED);
}
if (null_fd > STDERR_FILENO)
(void) close(null_fd);
init_verbose(VERBOSE_BASE_LEVEL);
toollib: tweak background forking Log what is forked and replace #if 1 with DEBUG_CHILD.
2013-09-06 04:49:43 +04:00
#endif /* DEBUG_CHILD */
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
strncpy(*cmd->argv, "(lvm2)", strlen(*cmd->argv));
if (!skip_lvm) {
reset_locking();
lvmcache: handle reinit without error Since commit f12ee43f2eaba5d38b1925a5a34b1746c1d66985 call destroy, it start to check all VGs are unlocked. However when we become_daemon, we simply reset locking (since lock is still kept by parent process). So implement a simple 'reset' flag.
2014-03-22 01:26:39 +04:00
lvmcache_destroy(cmd, 1, 1);
clvmd: separate saved_vg from vginfo The clvmd saved_vg data is independent from the normal lvm lvmcache vginfo data, so separate saved_vg from vginfo. Normal lvm doesn't need to use save_vg at all, and in clvmd, lvmcache changes on vginfo can be made without worrying about unwanted effects on saved_vg.
2018-05-03 00:58:49 +03:00
if (!lvmcache_init(cmd))
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
/* FIXME Clean up properly here */
_exit(ECMD_FAILED);
}
cov: mask some warning about leakage Mask false-positive leak report.
2021-09-19 21:21:55 +03:00
/* coverity[leaked_handle] null_fd does not leak here */
tools: add -b/--background for pvscan --cache -aay Udev daemon has recently introduced a limit on the number of udev processes (there was no limit before). This causes a problem when calling pvscan --cache -aay in lvmetad udev rules which is supposed to activate the volumes. This activation is itself synced with udev and so it waits for the activation to complete before the pvscan finishes. The event processing can't continue until this pvscan call is finished. But if we're at the limit with the udev process count, we can't instatiate any more udev processes, all such events are queued and so we can't process the lvm activation event for which the pvscan is waiting. Then we're in a deadlock since the udev process with the pvscan --cache -aay call waits for the lvm activation udev processing to complete, but that will never happen as there's this limit hit with the number of udev processes. The process with pvscan --cache -aay actually times out eventually (3min or 30sec, depends on the version of udev). This patch makes it possible to run the pvscan --cache -aay in the background so the udev processing can continue and hence we can avoid the deadlock mentioned above.
2013-09-03 18:06:16 +04:00
return 1;
}
Add skip_dev_dir() to process command line VGs.
2006-08-26 03:02:33 +04:00
/*
* Strip dev_dir if present
*/
Const fixing Fixing some const warnings - with API change in: int vg_extend(struct volume_group *vg, int pv_count, const char *const *pv_names, Change is needed - as lvm2api expects const behaviour here. So vg_extend() is doing local strdup for unescaping. skip_dev_dir return const char* from const char* vg_name. Rest of the patch is cleanup of related warnings. Also using dm_report_filed_string() API change to simplify casting in _string_disp and _lvname_disp.
2011-02-18 17:47:28 +03:00
const char *skip_dev_dir(struct cmd_context *cmd, const char *vg_name,
cleanup: indent changes
2014-07-11 14:25:18 +04:00
unsigned *dev_dir_found)
Add skip_dev_dir() to process command line VGs.
2006-08-26 03:02:33 +04:00
{
toollib: refactor skip_dev_dir Detect dev dir just once.
2014-09-28 14:54:20 +04:00
size_t devdir_len = strlen(cmd->dev_dir);
const char *dmdir = dm_dir() + devdir_len;
Support the /dev/mapper prefix on most command lines.
2007-03-09 23:47:41 +03:00
size_t dmdir_len = strlen(dmdir), vglv_sz;
cov: add some initializers
2021-09-10 23:32:44 +03:00
char *vgname = NULL, *lvname, *layer, *vglv;
Add skip_dev_dir() to process command line VGs.
2006-08-26 03:02:33 +04:00
Support the /dev/mapper prefix on most command lines.
2007-03-09 23:47:41 +03:00
/* FIXME Do this properly */
toollib: refactor skip_dev_dir Detect dev dir just once.
2014-09-28 14:54:20 +04:00
if (*vg_name == '/')
while (vg_name[1] == '/')
Add skip_dev_dir() to process command line VGs.
2006-08-26 03:02:33 +04:00
vg_name++;
toollib: refactor skip_dev_dir Detect dev dir just once.
2014-09-28 14:54:20 +04:00
if (strncmp(vg_name, cmd->dev_dir, devdir_len)) {
if (dev_dir_found)
*dev_dir_found = 0;
} else {
Support the /dev/mapper prefix on most command lines.
2007-03-09 23:47:41 +03:00
if (dev_dir_found)
*dev_dir_found = 1;
toollib: refactor skip_dev_dir Detect dev dir just once.
2014-09-28 14:54:20 +04:00
vg_name += devdir_len;
Support the /dev/mapper prefix on most command lines.
2007-03-09 23:47:41 +03:00
while (*vg_name == '/')
vg_name++;
toollib: refactor skip_dev_dir Detect dev dir just once.
2014-09-28 14:54:20 +04:00
/* Reformat string if /dev/mapper found */
toollib: fix regression in parsing /dev/mapper/vg-lv Commit b0dde9e8f026ddd679 introduced regression in parsing /dev/mapper prefix - and tried to check for '/' one char behind.
2014-11-26 19:09:47 +03:00
if (!strncmp(vg_name, dmdir, dmdir_len) && vg_name[dmdir_len] == '/') {
vg_name += dmdir_len + 1;
toollib: refactor skip_dev_dir Detect dev dir just once.
2014-09-28 14:54:20 +04:00
while (*vg_name == '/')
vg_name++;
if (!dm_split_lvm_name(cmd->mem, vg_name, &vgname, &lvname, &layer) ||
*layer) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("skip_dev_dir: Couldn't split up device name %s.",
toollib: refactor skip_dev_dir Detect dev dir just once.
2014-09-28 14:54:20 +04:00
vg_name);
return vg_name;
}
vglv_sz = strlen(vgname) + strlen(lvname) + 2;
if (!(vglv = dm_pool_alloc(cmd->mem, vglv_sz)) ||
dm_snprintf(vglv, vglv_sz, "%s%s%s", vgname,
*lvname ? "/" : "",
lvname) < 0) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("vg/lv string alloc failed.");
toollib: refactor skip_dev_dir Detect dev dir just once.
2014-09-28 14:54:20 +04:00
return vg_name;
}
return vglv;
Support the /dev/mapper prefix on most command lines.
2007-03-09 23:47:41 +03:00
}
}
Const fixing Fixing some const warnings - with API change in: int vg_extend(struct volume_group *vg, int pv_count, const char *const *pv_names, Change is needed - as lvm2api expects const behaviour here. So vg_extend() is doing local strdup for unescaping. skip_dev_dir return const char* from const char* vg_name. Rest of the patch is cleanup of related warnings. Also using dm_report_filed_string() API change to simplify casting in _string_disp and _lvname_disp.
2011-02-18 17:47:28 +03:00
return vg_name;
Add skip_dev_dir() to process command line VGs.
2006-08-26 03:02:33 +04:00
}
Print advice about changing clustered VGs to shared
2018-06-18 18:59:11 +03:00
static int _printed_clustered_vg_advice = 0;
cmdline: Add --ignoreskippedcluster. Accept --ignoreskippedcluster with pvs, vgs, lvs, pvdisplay, vgdisplay, lvdisplay, vgchange and lvchange to avoid the 'Skipping clustered VG' errors when requesting information about a clustered VG without using clustered locking and still exit with success. The messages can still be seen with -v.
2013-10-02 00:20:10 +04:00
/*
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
* Three possible results:
* a) return 0, skip 0: take the VG, and cmd will end in success
* b) return 0, skip 1: skip the VG, and cmd will end in success
* c) return 1, skip *: skip the VG, and cmd will end in failure
*
* Case b is the special case, and includes the following:
* . The VG is inconsistent, and the command allows for inconsistent VGs.
* . The VG is clustered, the host cannot access clustered VG's,
* and the command option has been used to ignore clustered vgs.
*
* Case c covers the other errors returned when reading the VG.
pvs: Hide inaccessible clustered PVs. Inaccessible clustered PVs can be hidden from pvs -a in the same way as foreign PVs, rather than showing them as if they do not belong to a VG.
2015-03-19 02:31:46 +03:00
* If *skip is 1, it's OK for the caller to read the list of PVs in the VG.
cmdline: Add --ignoreskippedcluster. Accept --ignoreskippedcluster with pvs, vgs, lvs, pvdisplay, vgdisplay, lvdisplay, vgchange and lvchange to avoid the 'Skipping clustered VG' errors when requesting information about a clustered VG without using clustered locking and still exit with success. The messages can still be seen with -v.
2013-10-02 00:20:10 +04:00
*/
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
static int _ignore_vg(struct cmd_context *cmd,
uint32_t error_flags, struct volume_group *error_vg,
const char *vg_name, struct dm_list *arg_vgnames,
uint32_t read_flags, int *skip, int *notfound)
cmdline: Add --ignoreskippedcluster. Accept --ignoreskippedcluster with pvs, vgs, lvs, pvdisplay, vgdisplay, lvdisplay, vgchange and lvchange to avoid the 'Skipping clustered VG' errors when requesting information about a clustered VG without using clustered locking and still exit with success. The messages can still be seen with -v.
2013-10-02 00:20:10 +04:00
{
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
uint32_t read_error = error_flags;
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
*skip = 0;
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
*notfound = 0;
cmdline: Add --ignoreskippedcluster. Accept --ignoreskippedcluster with pvs, vgs, lvs, pvdisplay, vgdisplay, lvdisplay, vgchange and lvchange to avoid the 'Skipping clustered VG' errors when requesting information about a clustered VG without using clustered locking and still exit with success. The messages can still be seen with -v.
2013-10-02 00:20:10 +04:00
vg_read: sometimes ignore read errors Running "vgremove -f VG & pvs" results in the pvs command reporting that the VG is not found or is inconsistent. If the VG is gone or being removed, the pvs command should just skip it and not print errors about it. "Not found" is because the pvs command created the list of VGs to process, including VG, then vgremove removed the VG, then the pvs command came to to read the VG to process it and did not find it. An "inconsistent" error could be reported if vgremove had only partially completed removing VG when pvs did vg_read on the VG to process it, causing pvs to find the VG in a partially-removed state. This fix adds a flag that pvs uses to ignore a VG that can't be read or is inconsistent.
2015-10-22 22:56:22 +03:00
if ((read_error & FAILED_NOTFOUND) && (read_flags & READ_OK_NOTFOUND)) {
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
*notfound = 1;
vg_read: sometimes ignore read errors Running "vgremove -f VG & pvs" results in the pvs command reporting that the VG is not found or is inconsistent. If the VG is gone or being removed, the pvs command should just skip it and not print errors about it. "Not found" is because the pvs command created the list of VGs to process, including VG, then vgremove removed the VG, then the pvs command came to to read the VG to process it and did not find it. An "inconsistent" error could be reported if vgremove had only partially completed removing VG when pvs did vg_read on the VG to process it, causing pvs to find the VG in a partially-removed state. This fix adds a flag that pvs uses to ignore a VG that can't be read or is inconsistent.
2015-10-22 22:56:22 +03:00
return 0;
}
Drop --ignoreskippedcluster option It's no longer needed. Clustered VGs are now handled in the same way as foreign VGs, and as shared VGs that can't be accessed: - A command processing all VGs sees a clustered VG, prints a message ("Skipping clustered VG foo."), skips it, and does not fail. - A command where the clustered VG is explicitly named on the command line, prints a message and fails. "Cannot access clustered VG foo, see lvmlockd(8)." The option is listed in the set of ignored options for the commands that previously accepted it. (Removing it entirely would cause commands/scripts to fail if they set it.)
2018-06-15 23:43:59 +03:00
if (read_error & FAILED_CLUSTERED) {
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
if (arg_vgnames && str_list_match_item(arg_vgnames, vg_name)) {
log_error("Cannot access clustered VG %s.", vg_name);
Print advice about changing clustered VGs to shared
2018-06-18 18:59:11 +03:00
if (!_printed_clustered_vg_advice) {
_printed_clustered_vg_advice = 1;
log_error("See lvmlockd(8) for changing a clvm/clustered VG to a shared VG.");
}
Drop --ignoreskippedcluster option It's no longer needed. Clustered VGs are now handled in the same way as foreign VGs, and as shared VGs that can't be accessed: - A command processing all VGs sees a clustered VG, prints a message ("Skipping clustered VG foo."), skips it, and does not fail. - A command where the clustered VG is explicitly named on the command line, prints a message and fails. "Cannot access clustered VG foo, see lvmlockd(8)." The option is listed in the set of ignored options for the commands that previously accepted it. (Removing it entirely would cause commands/scripts to fail if they set it.)
2018-06-15 23:43:59 +03:00
return 1;
} else {
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Skipping clustered VG %s.", vg_name);
Print advice about changing clustered VGs to shared
2018-06-18 18:59:11 +03:00
if (!_printed_clustered_vg_advice) {
_printed_clustered_vg_advice = 1;
log_error("See lvmlockd(8) for changing a clvm/clustered VG to a shared VG.");
}
Drop --ignoreskippedcluster option It's no longer needed. Clustered VGs are now handled in the same way as foreign VGs, and as shared VGs that can't be accessed: - A command processing all VGs sees a clustered VG, prints a message ("Skipping clustered VG foo."), skips it, and does not fail. - A command where the clustered VG is explicitly named on the command line, prints a message and fails. "Cannot access clustered VG foo, see lvmlockd(8)." The option is listed in the set of ignored options for the commands that previously accepted it. (Removing it entirely would cause commands/scripts to fail if they set it.)
2018-06-15 23:43:59 +03:00
*skip = 1;
return 0;
}
cmdline: Add --ignoreskippedcluster. Accept --ignoreskippedcluster with pvs, vgs, lvs, pvdisplay, vgdisplay, lvdisplay, vgchange and lvchange to avoid the 'Skipping clustered VG' errors when requesting information about a clustered VG without using clustered locking and still exit with success. The messages can still be seen with -v.
2013-10-02 00:20:10 +04:00
}
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
if (read_error & FAILED_EXPORTED) {
if (arg_vgnames && str_list_match_item(arg_vgnames, vg_name)) {
log_error("Volume group %s is exported", vg_name);
return 1;
} else {
read_error &= ~FAILED_EXPORTED; /* Check for other errors */
log_verbose("Skipping exported volume group %s", vg_name);
*skip = 1;
}
}
system_id: use for VG ownership See included lvmsystemid(7) for full description.
2014-10-24 21:29:04 +04:00
/*
* Commands that operate on "all vgs" shouldn't be bothered by
* skipping a foreign VG, and the command shouldn't fail when
* one is skipped. But, if the command explicitly asked to
* operate on a foreign VG and it's skipped, then the command
* would expect to fail.
*/
if (read_error & FAILED_SYSTEMID) {
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
if (arg_vgnames && str_list_match_item(arg_vgnames, vg_name)) {
systemid: Init and merge lvm2 and lvm1 fields. Use system_id field in preference to lvm1_system_id. Initialise both for now.
2015-03-04 04:00:51 +03:00
log_error("Cannot access VG %s with system ID %s with %slocal system ID%s%s.",
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
vg_name,
error_vg ? error_vg->system_id : "unknown ",
cmd->system_id ? "" : "unknown ",
cmd->system_id ? " " : "",
cmd->system_id ? cmd->system_id : "");
system_id: use for VG ownership See included lvmsystemid(7) for full description.
2014-10-24 21:29:04 +04:00
return 1;
} else {
read_error &= ~FAILED_SYSTEMID; /* Check for other errors */
systemid: Fix access restrictions. When checking whether the system ID permits access to a VG, check for each permitted situation first, and only then issue the appropriate error message. Always issue a message for now. (We'll try to suppress some of those later when the VG concerned wasn't explicitly requested.) Add more messages to try to ensure every return code is checked and every error path (and only an error path) contains a log_error(). Add self-correction to vgchange -c to deal with situations where the cluster state and system ID state are out-of-sync (e.g. if old tools were used).
2015-02-24 02:19:36 +03:00
log_verbose("Skipping foreign volume group %s", vg_name);
system_id: use for VG ownership See included lvmsystemid(7) for full description.
2014-10-24 21:29:04 +04:00
*skip = 1;
}
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
/*
* Accessing a lockd VG when lvmlockd is not used is similar
* to accessing a foreign VG.
lockd: fix error message after a failing to get lock There are two different failure conditions detected in access_vg_lock_type() that should have different error messages. This adds another failure flag so the two cases can be distinguished to avoid printing a misleading error message.
2015-07-14 19:36:04 +03:00
* This is also the point where a command fails if it failed
* to acquire the necessary lock from lvmlockd.
* The two cases are distinguished by FAILED_LOCK_TYPE (the
* VG lock_type requires lvmlockd), and FAILED_LOCK_MODE (the
* command failed to acquire the necessary lock.)
Add lvmlockd
2015-03-05 23:00:44 +03:00
*/
lockd: fix error message after a failing to get lock There are two different failure conditions detected in access_vg_lock_type() that should have different error messages. This adds another failure flag so the two cases can be distinguished to avoid printing a misleading error message.
2015-07-14 19:36:04 +03:00
if (read_error & (FAILED_LOCK_TYPE | FAILED_LOCK_MODE)) {
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
if (arg_vgnames && str_list_match_item(arg_vgnames, vg_name)) {
lockd: fix error message after a failing to get lock There are two different failure conditions detected in access_vg_lock_type() that should have different error messages. This adds another failure flag so the two cases can be distinguished to avoid printing a misleading error message.
2015-07-14 19:36:04 +03:00
if (read_error & FAILED_LOCK_TYPE)
log_error("Cannot access VG %s with lock type %s that requires lvmlockd.",
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
vg_name,
error_vg ? error_vg->lock_type : "unknown");
lockd: fix error message after a failing to get lock There are two different failure conditions detected in access_vg_lock_type() that should have different error messages. This adds another failure flag so the two cases can be distinguished to avoid printing a misleading error message.
2015-07-14 19:36:04 +03:00
/* For FAILED_LOCK_MODE, the error is printed in vg_read. */
Add lvmlockd
2015-03-05 23:00:44 +03:00
return 1;
} else {
read_error &= ~FAILED_LOCK_TYPE; /* Check for other errors */
lockd: fix error message after a failing to get lock There are two different failure conditions detected in access_vg_lock_type() that should have different error messages. This adds another failure flag so the two cases can be distinguished to avoid printing a misleading error message.
2015-07-14 19:36:04 +03:00
read_error &= ~FAILED_LOCK_MODE;
Add lvmlockd
2015-03-05 23:00:44 +03:00
log_verbose("Skipping volume group %s", vg_name);
*skip = 1;
}
}
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
if (read_error != SUCCESS) {
pvs: Hide inaccessible clustered PVs. Inaccessible clustered PVs can be hidden from pvs -a in the same way as foreign PVs, rather than showing them as if they do not belong to a VG.
2015-03-19 02:31:46 +03:00
*skip = 0;
metadata: _vg_read: check if PV_EXT_USED flag is set correctly for orphan PVs and do a repair if needed If we know that the PV is orphan, meaning there's at least one MDA on that PV which does not reference any VG and at the same time there's PV_EXT_USED flag set, we're certainly in an inconsistent state and we need to fix this. For example, such situation can happen during vgremove/vgreduce if we removed/reduced the VG, but we haven't written PV headers yet because vgremove stopped abruptly for whatever reason just before writing new PV headers with updated state, including PV extension flags (and so the PV_EXT_USED flag). However, in case the PV has no MDAs at all, we can't double-check whether the PV_EXT_USED is correct or not - if that PV is marked as used, it's either: - really used (but other disks with MDAs are missing) - or the error state as described above is hit User needs to overwrite the PV header directly if it's really clear the PV having no MDAs does not belong to any VG and at the same time it's still marked as being in use (pvcreate -ff <dev_name> will fix this). For example - /dev/sda here has 1 MDA, orphan and is incorrectly marked with PV_EXT_USED flag: $ pvs --binary -o+pv_in_use WARNING: Found inconsistent standalone Physical Volumes. WARNING: Repairing flag incorrectly marking Physical Volume /dev/sda as used. PV VG Fmt Attr PSize PFree InUse /dev/sda lvm2 --- 128.00m 128.00m 0
2015-03-11 18:18:42 +03:00
if (is_orphan_vg(vg_name))
log_error("Cannot process standalone physical volumes");
else
log_error("Cannot process volume group %s", vg_name);
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
return 1;
}
return 0;
cmdline: Add --ignoreskippedcluster. Accept --ignoreskippedcluster with pvs, vgs, lvs, pvdisplay, vgdisplay, lvdisplay, vgchange and lvchange to avoid the 'Skipping clustered VG' errors when requesting information about a clustered VG without using clustered locking and still exit with success. The messages can still be seen with -v.
2013-10-02 00:20:10 +04:00
}
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
/*
* This functiona updates the "selected" arg only if last item processed
* is selected so this implements the "whole structure is selected if
* at least one of its items is selected".
*/
static void _update_selection_result(struct processing_handle *handle, int *selected)
{
if (!handle || !handle->selection_handle)
return;
if (handle->selection_handle->selected)
*selected = 1;
}
static void _set_final_selection_result(struct processing_handle *handle, int selected)
{
if (!handle || !handle->selection_handle)
return;
handle->selection_handle->selected = selected;
}
Add some comments.
2005-01-19 20:31:51 +03:00
/*
* Metadata iteration functions
*/
Initial pv_segment code.
2005-04-20 00:58:25 +04:00
int process_each_segment_in_pv(struct cmd_context *cmd,
struct volume_group *vg,
struct physical_volume *pv,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct processing_handle *handle,
Use typedefs for toollib process_each functions.
2010-04-14 03:57:41 +04:00
process_single_pvseg_fn_t process_single_pvseg)
Initial pv_segment code.
2005-04-20 00:58:25 +04:00
{
struct pv_segment *pvseg;
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
int whole_selected = 0;
Fix return values for reporting commands when run with no PVs, LVs, or VGs. The new error checking code caught some commands that were returning '0' as an exit status for success. This is incorrect and resulted in a benign error message displayed (see below). As of today, all commands should return a value defined in lib/commands/errors.h (1-5). This results in an exit code of 0 on success, or > 0 on failure (as stated in the lvm.8 man page). Before change: 1. Make sure no PVs are on the system 2. Run 'pvs' Command failed with status code 0. After change: <no output>
2008-06-11 00:07:04 +04:00
int ret_max = ECMD_PROCESSED;
Initial pv_segment code.
2005-04-20 00:58:25 +04:00
int ret;
Fix pvseg report for orphan PVs and other devices. If user requests report attribute from PVSEG type and PV is orphan (or all devices is set), the report is empty. Try for example (when only orphan PV are present) #pvs #pvs -o +devices # pvs /dev/sdb1 PV VG Fmt Attr PSize PFree /dev/sdb1 lvm2 -- 46.58G 46.58G # pvs -o +devices /dev/sdb1 (no output) The problem is caused by empty pv->segments list. Fix it by providing fake segment here (similar to fake structures in _pvsegs_sub_single() calls.
2009-04-21 16:59:18 +04:00
struct pv_segment _free_pv_segment = { .pv = pv };
Avoid nested vg_reads when processing PVs in VGs and fix associated locking.
2007-11-14 21:41:05 +03:00
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (dm_list_empty(&pv->segments)) {
ret = process_single_pvseg(cmd, NULL, &_free_pv_segment, handle);
if (ret != ECMD_PROCESSED)
stack;
if (ret > ret_max)
ret_max = ret;
} else {
Fix pvseg report for orphan PVs and other devices. If user requests report attribute from PVSEG type and PV is orphan (or all devices is set), the report is empty. Try for example (when only orphan PV are present) #pvs #pvs -o +devices # pvs /dev/sdb1 PV VG Fmt Attr PSize PFree /dev/sdb1 lvm2 -- 46.58G 46.58G # pvs -o +devices /dev/sdb1 (no output) The problem is caused by empty pv->segments list. Fix it by providing fake segment here (similar to fake structures in _pvsegs_sub_single() calls.
2009-04-21 16:59:18 +04:00
dm_list_iterate_items(pvseg, &pv->segments) {
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
if (sigint_caught())
return_ECMD_FAILED;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
ret = process_single_pvseg(cmd, vg, pvseg, handle);
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
_update_selection_result(handle, &whole_selected);
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (ret != ECMD_PROCESSED)
sigint: improve logic on for sigint reaction Fix and improve handling on sigint. Always check for signal presence *before* calling of command, so it will not call the command when break was hit. If the command has been finished succesfully there is no problem to mark the command ok and not report interrupt at all. Fix cuple related stack; reports and assignments.
2013-07-01 18:30:12 +04:00
stack;
Fix pvseg report for orphan PVs and other devices. If user requests report attribute from PVSEG type and PV is orphan (or all devices is set), the report is empty. Try for example (when only orphan PV are present) #pvs #pvs -o +devices # pvs /dev/sdb1 PV VG Fmt Attr PSize PFree /dev/sdb1 lvm2 -- 46.58G 46.58G # pvs -o +devices /dev/sdb1 (no output) The problem is caused by empty pv->segments list. Fix it by providing fake segment here (similar to fake structures in _pvsegs_sub_single() calls.
2009-04-21 16:59:18 +04:00
if (ret > ret_max)
ret_max = ret;
}
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
}
Avoid nested vg_reads when processing PVs in VGs and fix associated locking.
2007-11-14 21:41:05 +03:00
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
/* the PV is selected if at least one PV segment is selected */
_set_final_selection_result(handle, whole_selected);
Initial pv_segment code.
2005-04-20 00:58:25 +04:00
return ret_max;
}
New column-based reporting tools: lvs, pvs & vgs.
2002-12-12 23:55:49 +03:00
int process_each_segment_in_lv(struct cmd_context *cmd,
struct logical_volume *lv,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct processing_handle *handle,
Use typedefs for toollib process_each functions.
2010-04-14 03:57:41 +04:00
process_single_seg_fn_t process_single_seg)
New column-based reporting tools: lvs, pvs & vgs.
2002-12-12 23:55:49 +03:00
{
struct lv_segment *seg;
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
int whole_selected = 0;
Fix return values for reporting commands when run with no PVs, LVs, or VGs. The new error checking code caught some commands that were returning '0' as an exit status for success. This is incorrect and resulted in a benign error message displayed (see below). As of today, all commands should return a value defined in lib/commands/errors.h (1-5). This results in an exit code of 0 on success, or > 0 on failure (as stated in the lvm.8 man page). Before change: 1. Make sure no PVs are on the system 2. Run 'pvs' Command failed with status code 0. After change: <no output>
2008-06-11 00:07:04 +04:00
int ret_max = ECMD_PROCESSED;
New column-based reporting tools: lvs, pvs & vgs.
2002-12-12 23:55:49 +03:00
int ret;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(seg, &lv->segments) {
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (sigint_caught())
return_ECMD_FAILED;
ret = process_single_seg(cmd, seg, handle);
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
_update_selection_result(handle, &whole_selected);
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (ret != ECMD_PROCESSED)
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
stack;
New column-based reporting tools: lvs, pvs & vgs.
2002-12-12 23:55:49 +03:00
if (ret > ret_max)
ret_max = ret;
}
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
/* the LV is selected if at least one LV segment is selected */
_set_final_selection_result(handle, whole_selected);
New column-based reporting tools: lvs, pvs & vgs.
2002-12-12 23:55:49 +03:00
return ret_max;
}
toollib: refactor extract_vgname Split internals of extract_vgname into _extract_vgname. This common code will be used for other similar function. Reuse skip_dev_dir() instead of less mature coded to skip device dir. Instead of duplicating full vg/lv name - allocate string only vg portion of lv name.
2014-09-27 18:29:43 +04:00
static const char *_extract_vgname(struct cmd_context *cmd, const char *lv_name,
const char **after)
{
const char *vg_name = lv_name;
char *st, *pos;
/* Strip dev_dir (optional) */
if (!(vg_name = skip_dev_dir(cmd, vg_name, NULL)))
return_0;
/* Require exactly one set of consecutive slashes */
if ((st = pos = strchr(vg_name, '/')))
while (*st == '/')
st++;
if (!st || strchr(st, '/')) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("\"%s\": Invalid path for Logical Volume.",
toollib: refactor extract_vgname Split internals of extract_vgname into _extract_vgname. This common code will be used for other similar function. Reuse skip_dev_dir() instead of less mature coded to skip device dir. Instead of duplicating full vg/lv name - allocate string only vg portion of lv name.
2014-09-27 18:29:43 +04:00
lv_name);
return 0;
}
if (!(vg_name = dm_pool_strndup(cmd->mem, vg_name, pos - vg_name))) {
log_error("Allocation of vg_name failed.");
return 0;
}
if (after)
*after = st;
return vg_name;
}
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
toollib: Remove unused functions from header file.
2014-10-06 18:22:01 +04:00
/*
* Extract default volume group name from environment
*/
static const char *_default_vgname(struct cmd_context *cmd)
{
const char *vg_path;
/* Take default VG from environment? */
vg_path = getenv("LVM_VG_NAME");
if (!vg_path)
return 0;
vg_path = skip_dev_dir(cmd, vg_path, NULL);
if (strchr(vg_path, '/')) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("\"%s\": Invalid environment var LVM_VG_NAME set for Volume Group.",
vg_path);
toollib: Remove unused functions from header file.
2014-10-06 18:22:01 +04:00
return 0;
}
return dm_pool_strdup(cmd->mem, vg_path);
}
Add some comments.
2005-01-19 20:31:51 +03:00
/*
* Determine volume group name from a logical volume name
*/
Default stripesize 64k & config file setting for it; Clear many compiler warnings (i386) & associated bugs - hopefully without introducing too many new bugs:-) (Same exercise required for other archs.) Default compilation has optimisation - or else use ./configure --enable-debug
2002-12-20 02:25:55 +03:00
const char *extract_vgname(struct cmd_context *cmd, const char *lv_name)
More LV-related tidying. lvdisplay without args now shows all LVs.
2001-11-14 21:38:07 +03:00
{
Default stripesize 64k & config file setting for it; Clear many compiler warnings (i386) & associated bugs - hopefully without introducing too many new bugs:-) (Same exercise required for other archs.) Default compilation has optimisation - or else use ./configure --enable-debug
2002-12-20 02:25:55 +03:00
const char *vg_name = lv_name;
lvremove
2001-10-29 16:52:23 +03:00
/* Path supplied? */
lvcreate
2001-11-06 22:02:26 +03:00
if (vg_name && strchr(vg_name, '/')) {
toollib: refactor extract_vgname Split internals of extract_vgname into _extract_vgname. This common code will be used for other similar function. Reuse skip_dev_dir() instead of less mature coded to skip device dir. Instead of duplicating full vg/lv name - allocate string only vg portion of lv name.
2014-09-27 18:29:43 +04:00
if (!(vg_name = _extract_vgname(cmd, lv_name, NULL)))
return_NULL;
tagging
2004-03-08 20:19:15 +03:00
lvremove
2001-10-29 16:52:23 +03:00
return vg_name;
}
lvcreate
2001-11-06 22:02:26 +03:00
toollib: Remove unused functions from header file.
2014-10-06 18:22:01 +04:00
if (!(vg_name = _default_vgname(cmd))) {
lvcreate
2001-11-06 22:02:26 +03:00
if (lv_name)
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("Path required for Logical Volume \"%s\".",
More LV-related tidying. lvdisplay without args now shows all LVs.
2001-11-14 21:38:07 +03:00
lv_name);
toollib: refactor extract_vgname Split internals of extract_vgname into _extract_vgname. This common code will be used for other similar function. Reuse skip_dev_dir() instead of less mature coded to skip device dir. Instead of duplicating full vg/lv name - allocate string only vg portion of lv name.
2014-09-27 18:29:43 +04:00
return NULL;
lvcreate
2001-11-06 22:02:26 +03:00
}
More LV-related tidying. lvdisplay without args now shows all LVs.
2001-11-14 21:38:07 +03:00
lvcreate
2001-11-06 22:02:26 +03:00
return vg_name;
}
cleanup: some missed public symbols static
2024-05-13 12:18:20 +03:00
static const char _pe_size_may_not_be_negative_msg[] = "Physical extent size may not be negative.";
conf: add allocation/physical_extent_size config option for default PE size of VGs. Removes a need to use "vgcreate -s <desired PE size>" all the time time just to override hardcoded default which is 4096KiB.
2014-09-12 12:03:12 +04:00
int vgcreate_params_set_defaults(struct cmd_context *cmd,
struct vgcreate_params *vp_def,
struct volume_group *vg)
Add vgcreate_params_set_defaults(). Add function to set default vgcreate parameters based on existing VG or internal defaults. Should be no functional change.
2009-11-01 23:02:32 +03:00
{
conf: add allocation/physical_extent_size config option for default PE size of VGs. Removes a need to use "vgcreate -s <desired PE size>" all the time time just to override hardcoded default which is 4096KiB.
2014-09-12 12:03:12 +04:00
int64_t extent_size;
systemid: Fix access restrictions. When checking whether the system ID permits access to a VG, check for each permitted situation first, and only then issue the appropriate error message. Always issue a message for now. (We'll try to suppress some of those later when the VG concerned wasn't explicitly requested.) Add more messages to try to ensure every return code is checked and every error path (and only an error path) contains a log_error(). Add self-correction to vgchange -c to deal with situations where the cluster state and system ID state are out-of-sync (e.g. if old tools were used).
2015-02-24 02:19:36 +03:00
/* Only vgsplit sets vg */
Add vgcreate_params_set_defaults(). Add function to set default vgcreate parameters based on existing VG or internal defaults. Should be no functional change.
2009-11-01 23:02:32 +03:00
if (vg) {
vp_def->vg_name = NULL;
vp_def->extent_size = vg->extent_size;
vp_def->max_pv = vg->max_pv;
vp_def->max_lv = vg->max_lv;
vp_def->alloc = vg->alloc;
improve vgmetadatacopies unmanaged message
2010-07-01 00:03:52 +04:00
vp_def->vgmetadatacopies = vg->mda_copies;
systemid: Fix access restrictions. When checking whether the system ID permits access to a VG, check for each permitted situation first, and only then issue the appropriate error message. Always issue a message for now. (We'll try to suppress some of those later when the VG concerned wasn't explicitly requested.) Add more messages to try to ensure every return code is checked and every error path (and only an error path) contains a log_error(). Add self-correction to vgchange -c to deal with situations where the cluster state and system ID state are out-of-sync (e.g. if old tools were used).
2015-02-24 02:19:36 +03:00
vp_def->system_id = vg->system_id; /* No need to clone this */
Add vgcreate_params_set_defaults(). Add function to set default vgcreate parameters based on existing VG or internal defaults. Should be no functional change.
2009-11-01 23:02:32 +03:00
} else {
vp_def->vg_name = NULL;
conf: add allocation/physical_extent_size config option for default PE size of VGs. Removes a need to use "vgcreate -s <desired PE size>" all the time time just to override hardcoded default which is 4096KiB.
2014-09-12 12:03:12 +04:00
extent_size = find_config_tree_int64(cmd,
allocation_physical_extent_size_CFG, NULL) * 2;
if (extent_size < 0) {
log_error(_pe_size_may_not_be_negative_msg);
return 0;
}
vp_def->extent_size = (uint32_t) extent_size;
Add vgcreate_params_set_defaults(). Add function to set default vgcreate parameters based on existing VG or internal defaults. Should be no functional change.
2009-11-01 23:02:32 +03:00
vp_def->max_pv = DEFAULT_MAX_PV;
vp_def->max_lv = DEFAULT_MAX_LV;
vp_def->alloc = DEFAULT_ALLOC_POLICY;
improve vgmetadatacopies unmanaged message
2010-07-01 00:03:52 +04:00
vp_def->vgmetadatacopies = DEFAULT_VGMETADATACOPIES;
systemid: Fix access restrictions. When checking whether the system ID permits access to a VG, check for each permitted situation first, and only then issue the appropriate error message. Always issue a message for now. (We'll try to suppress some of those later when the VG concerned wasn't explicitly requested.) Add more messages to try to ensure every return code is checked and every error path (and only an error path) contains a log_error(). Add self-correction to vgchange -c to deal with situations where the cluster state and system ID state are out-of-sync (e.g. if old tools were used).
2015-02-24 02:19:36 +03:00
vp_def->system_id = cmd->system_id;
Add vgcreate_params_set_defaults(). Add function to set default vgcreate parameters based on existing VG or internal defaults. Should be no functional change.
2009-11-01 23:02:32 +03:00
}
conf: add allocation/physical_extent_size config option for default PE size of VGs. Removes a need to use "vgcreate -s <desired PE size>" all the time time just to override hardcoded default which is 4096KiB.
2014-09-12 12:03:12 +04:00
return 1;
Add vgcreate_params_set_defaults(). Add function to set default vgcreate parameters based on existing VG or internal defaults. Should be no functional change.
2009-11-01 23:02:32 +03:00
}
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
/*
Rename fill_vg_create_params to vgcreate_params_set_from_args. Rename fill_vg_create_params to vgcreate_params_set_from_args and remove vg_name parameter from function (caller must set before calling function).
2009-11-01 23:03:24 +03:00
* Set members of struct vgcreate_params from cmdline arguments.
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
* Do preliminary validation with arg_*() interface.
* Further, more generic validation is done in validate_vgcreate_params().
Create vgs_are_compatible() fn to check whether vgs are compatible for merging. Add new vgmerge and vgsplit tests to check rejection of incompatible vgs. Cleanup comments. Bugzilla: bz251992 --- lib/metadata/metadata-exported.h | 3 + lib/metadata/metadata.c | 89 +++++++++++++++++++++++++++++++++- test/t-vgmerge-usage.sh | 101 +++++++++++++++++++++++++++++++++++++++ test/t-vgsplit-operation.sh | 20 +++++++ tools/vgmerge.c | 69 -------------------------- tools/vgsplit.c | 5 - 6 files changed, 215 insertions(+), 72 deletions(-)
2008-01-16 22:54:39 +03:00
* This function is to remain in tools directory.
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
*/
Rename fill_vg_create_params to vgcreate_params_set_from_args. Rename fill_vg_create_params to vgcreate_params_set_from_args and remove vg_name parameter from function (caller must set before calling function).
2009-11-01 23:03:24 +03:00
int vgcreate_params_set_from_args(struct cmd_context *cmd,
struct vgcreate_params *vp_new,
struct vgcreate_params *vp_def)
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
{
systemid: Fix access restrictions. When checking whether the system ID permits access to a VG, check for each permitted situation first, and only then issue the appropriate error message. Always issue a message for now. (We'll try to suppress some of those later when the VG concerned wasn't explicitly requested.) Add more messages to try to ensure every return code is checked and every error path (and only an error path) contains a log_error(). Add self-correction to vgchange -c to deal with situations where the cluster state and system ID state are out-of-sync (e.g. if old tools were used).
2015-02-24 02:19:36 +03:00
const char *system_id_arg_str;
Add lvmlockd
2015-03-05 23:00:44 +03:00
const char *lock_type = NULL;
int use_lvmlockd;
lock_type_t lock_type_num;
system_id: use for VG ownership See included lvmsystemid(7) for full description.
2014-10-24 21:29:04 +04:00
Remove clvmd and associated code More code reduction and simplification can follow.
2018-06-05 18:47:01 +03:00
if (arg_is_set(cmd, clustered_ARG)) {
log_error("The clustered option is deprecated, see --shared.");
return 0;
}
Rename fill_vg_create_params to vgcreate_params_set_from_args. Rename fill_vg_create_params to vgcreate_params_set_from_args and remove vg_name parameter from function (caller must set before calling function).
2009-11-01 23:03:24 +03:00
vp_new->vg_name = skip_dev_dir(cmd, vp_def->vg_name, NULL);
Move more parameter validation into the library. Update vgrename to call validate_vg_rename_params(). Fix vgcreate and vgsplit default arguments by adding defaults parameter to fill_vg_create_params(). Add t-vgrename-usage.sh test. Bugzilla: bz251992 --- tools/toollib.c | 32 ++++++++------------------------ tools/toollib.h | 5 ++--- tools/vgcreate.c | 35 +++++++++++++++++++++-------------- tools/vgrename.c | 35 ++++++----------------------------- tools/vgsplit.c | 21 ++++++++++++++------- 5 files changed, 51 insertions(+), 77 deletions(-)
2008-01-16 01:56:30 +03:00
vp_new->max_lv = arg_uint_value(cmd, maxlogicalvolumes_ARG,
vp_def->max_lv);
vp_new->max_pv = arg_uint_value(cmd, maxphysicalvolumes_ARG,
vp_def->max_pv);
Correct enum type Using debug_t and some forgetten alloc_policy_t, force_t from past commit.
2012-03-02 01:14:43 +04:00
vp_new->alloc = (alloc_policy_t) arg_uint_value(cmd, alloc_ARG, vp_def->alloc);
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
/* Units of 512-byte sectors */
Move more parameter validation into the library. Update vgrename to call validate_vg_rename_params(). Fix vgcreate and vgsplit default arguments by adding defaults parameter to fill_vg_create_params(). Add t-vgrename-usage.sh test. Bugzilla: bz251992 --- tools/toollib.c | 32 ++++++++------------------------ tools/toollib.h | 5 ++--- tools/vgcreate.c | 35 +++++++++++++++++++++-------------- tools/vgrename.c | 35 ++++++----------------------------- tools/vgsplit.c | 21 ++++++++++++++------- 5 files changed, 51 insertions(+), 77 deletions(-)
2008-01-16 01:56:30 +03:00
vp_new->extent_size =
arg_uint_value(cmd, physicalextentsize_ARG, vp_def->extent_size);
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
Using enum types for enums alloc_policy_t, dm_string_mangling_t, percent_range_t, sign_t
2012-02-28 18:24:57 +04:00
if (arg_sign_value(cmd, physicalextentsize_ARG, SIGN_NONE) == SIGN_MINUS) {
conf: add allocation/physical_extent_size config option for default PE size of VGs. Removes a need to use "vgcreate -s <desired PE size>" all the time time just to override hardcoded default which is 4096KiB.
2014-09-12 12:03:12 +04:00
log_error(_pe_size_may_not_be_negative_msg);
cleanup: swap return values Use lvm standard return code for success/fail 1/0.
2012-10-16 12:07:27 +04:00
return 0;
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
}
PE size overflows, on most architectures it is catch by "PE cannot be 0" but s390x unfortunately return something usable. Always use unit64 in inital parameter check.
2011-03-02 23:00:09 +03:00
if (arg_uint64_value(cmd, physicalextentsize_ARG, 0) > MAX_EXTENT_SIZE) {
cleanup: reformat sentence about max sizes The extent size must fits all blocks in 4294967295 sectors (in 512b units) this is 1/2 KiB less then 2TiB. So while previous statement 'suggested' 2TiB is still acceptable value, make it clear it's not. As now we support any multiples of 128KB as extent size - values like 2047G will still 'flow-in' otherwise the largest power-of-2 supported value is 1TiB. With 1TiB user needs 8388608 extents for 8EiB device. (FYI such device is already unusable with todays glibc-2.22.90-27) 4GiB extent size is currently the smallest extent size which allows a user to create 8EiB devices (with 2GiB it's less then 8EiB). TODO: lvm2 may possibly print amount of 'lost/unused space' on a PV, since using such ridiculously sized extent size may result in huge space being left unaccessible.
2016-01-19 18:07:39 +03:00
log_error("Physical extent size must be smaller than %s.",
PE size overflows, on most architectures it is catch by "PE cannot be 0" but s390x unfortunately return something usable. Always use unit64 in inital parameter check.
2011-03-02 23:00:09 +03:00
display_size(cmd, (uint64_t) MAX_EXTENT_SIZE));
cleanup: swap return values Use lvm standard return code for success/fail 1/0.
2012-10-16 12:07:27 +04:00
return 0;
PE size overflows, on most architectures it is catch by "PE cannot be 0" but s390x unfortunately return something usable. Always use unit64 in inital parameter check.
2011-03-02 23:00:09 +03:00
}
Using enum types for enums alloc_policy_t, dm_string_mangling_t, percent_range_t, sign_t
2012-02-28 18:24:57 +04:00
if (arg_sign_value(cmd, maxlogicalvolumes_ARG, SIGN_NONE) == SIGN_MINUS) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("Max Logical Volumes may not be negative.");
cleanup: swap return values Use lvm standard return code for success/fail 1/0.
2012-10-16 12:07:27 +04:00
return 0;
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
}
Using enum types for enums alloc_policy_t, dm_string_mangling_t, percent_range_t, sign_t
2012-02-28 18:24:57 +04:00
if (arg_sign_value(cmd, maxphysicalvolumes_ARG, SIGN_NONE) == SIGN_MINUS) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("Max Physical Volumes may not be negative.");
cleanup: swap return values Use lvm standard return code for success/fail 1/0.
2012-10-16 12:07:27 +04:00
return 0;
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
}
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
if (arg_is_set(cmd, vgmetadatacopies_ARG))
improve vgmetadatacopies unmanaged message
2010-07-01 00:03:52 +04:00
vp_new->vgmetadatacopies = arg_int_value(cmd, vgmetadatacopies_ARG,
Add --vgmetadatacopies to vgcreate man page, command, and lvm.conf. Allow parsing of --vgmetadatacopies for vgcreate. Accept --metadatacopies as a synonym for --vgmetadatacopies. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
2010-06-29 00:38:23 +04:00
DEFAULT_VGMETADATACOPIES);
systemid: Fix access restrictions. When checking whether the system ID permits access to a VG, check for each permitted situation first, and only then issue the appropriate error message. Always issue a message for now. (We'll try to suppress some of those later when the VG concerned wasn't explicitly requested.) Add more messages to try to ensure every return code is checked and every error path (and only an error path) contains a log_error(). Add self-correction to vgchange -c to deal with situations where the cluster state and system ID state are out-of-sync (e.g. if old tools were used).
2015-02-24 02:19:36 +03:00
else
config: add profile arg to find_config_tree_int
2013-06-25 14:30:34 +04:00
vp_new->vgmetadatacopies = find_config_tree_int(cmd, metadata_vgmetadatacopies_CFG, NULL);
Add --vgmetadatacopies to vgcreate man page, command, and lvm.conf. Allow parsing of --vgmetadatacopies for vgcreate. Accept --metadatacopies as a synonym for --vgmetadatacopies. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
2010-06-29 00:38:23 +04:00
Add lvmlockd
2015-03-05 23:00:44 +03:00
if (!(system_id_arg_str = arg_str_value(cmd, systemid_ARG, NULL))) {
system_id: use for VG ownership See included lvmsystemid(7) for full description.
2014-10-24 21:29:04 +04:00
vp_new->system_id = vp_def->system_id;
Add lvmlockd
2015-03-05 23:00:44 +03:00
} else {
systemid: Fix access restrictions. When checking whether the system ID permits access to a VG, check for each permitted situation first, and only then issue the appropriate error message. Always issue a message for now. (We'll try to suppress some of those later when the VG concerned wasn't explicitly requested.) Add more messages to try to ensure every return code is checked and every error path (and only an error path) contains a log_error(). Add self-correction to vgchange -c to deal with situations where the cluster state and system ID state are out-of-sync (e.g. if old tools were used).
2015-02-24 02:19:36 +03:00
if (!(vp_new->system_id = system_id_from_string(cmd, system_id_arg_str)))
return_0;
system_id: use for VG ownership See included lvmsystemid(7) for full description.
2014-10-24 21:29:04 +04:00
systemid: Fix access restrictions. When checking whether the system ID permits access to a VG, check for each permitted situation first, and only then issue the appropriate error message. Always issue a message for now. (We'll try to suppress some of those later when the VG concerned wasn't explicitly requested.) Add more messages to try to ensure every return code is checked and every error path (and only an error path) contains a log_error(). Add self-correction to vgchange -c to deal with situations where the cluster state and system ID state are out-of-sync (e.g. if old tools were used).
2015-02-24 02:19:36 +03:00
/* FIXME Take local/extra_system_ids into account */
system_id: use for VG ownership See included lvmsystemid(7) for full description.
2014-10-24 21:29:04 +04:00
if (vp_new->system_id && cmd->system_id &&
systemid: Allow empty systemid with warnings. Add warning messages when empty system ID is set.
2015-02-25 17:12:24 +03:00
strcmp(vp_new->system_id, cmd->system_id)) {
if (*vp_new->system_id)
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: VG with system ID %s might become inaccessible as local system ID is %s",
systemid: Allow empty systemid with warnings. Add warning messages when empty system ID is set.
2015-02-25 17:12:24 +03:00
vp_new->system_id, cmd->system_id);
else
systemid: Improve concurrent warning.
2015-02-25 17:17:35 +03:00
log_warn("WARNING: A VG without a system ID allows unsafe access from other hosts.");
systemid: Allow empty systemid with warnings. Add warning messages when empty system ID is set.
2015-02-25 17:12:24 +03:00
}
system_id: use for VG ownership See included lvmsystemid(7) for full description.
2014-10-24 21:29:04 +04:00
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
if ((system_id_arg_str = arg_str_value(cmd, systemid_ARG, NULL))) {
vp_new->system_id = system_id_from_string(cmd, system_id_arg_str);
} else {
vp_new->system_id = vp_def->system_id;
}
if (system_id_arg_str) {
if (!vp_new->system_id || !vp_new->system_id[0])
log_warn("WARNING: A VG without a system ID allows unsafe access from other hosts.");
if (vp_new->system_id && cmd->system_id &&
strcmp(vp_new->system_id, cmd->system_id)) {
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: VG with system ID %s might become inaccessible as local system ID is %s",
Add lvmlockd
2015-03-05 23:00:44 +03:00
vp_new->system_id, cmd->system_id);
}
}
/*
* Locking: what kind of locking should be used for the
* new VG, and is it compatible with current lvm.conf settings.
*
* The end result is to set vp_new->lock_type to:
tools: Add support for "idm" lock type This patch is to update the comment and code to support "idm" lock type which is used for LVM toolkit. Signed-off-by: Leo Yan <leo.yan@linaro.org>
2021-05-07 05:25:16 +03:00
* none | clvm | dlm | sanlock | idm.
Add lvmlockd
2015-03-05 23:00:44 +03:00
*
* If 'vgcreate --lock-type <arg>' is set, the answer is given
tools: Add support for "idm" lock type This patch is to update the comment and code to support "idm" lock type which is used for LVM toolkit. Signed-off-by: Leo Yan <leo.yan@linaro.org>
2021-05-07 05:25:16 +03:00
* directly by <arg> which is one of none|clvm|dlm|sanlock|idm.
Add lvmlockd
2015-03-05 23:00:44 +03:00
*
* 'vgcreate --clustered y' is the way to create clvm VGs.
*
* 'vgcreate --shared' is the way to create lockd VGs.
tools: Add support for "idm" lock type This patch is to update the comment and code to support "idm" lock type which is used for LVM toolkit. Signed-off-by: Leo Yan <leo.yan@linaro.org>
2021-05-07 05:25:16 +03:00
* lock_type of sanlock, dlm or idm is selected based on
Add lvmlockd
2015-03-05 23:00:44 +03:00
* which lock manager is running.
*
*
* 1. Using neither clvmd nor lvmlockd.
* ------------------------------------------------
* lvm.conf:
* global/use_lvmlockd = 0
* global/locking_type = 1
*
* - no locking is enabled
* - clvmd is not used
* - lvmlockd is not used
* - VGs with CLUSTERED set are ignored (requires clvmd)
* - VGs with lockd type are ignored (requires lvmlockd)
* - vgcreate can create new VGs with lock_type none
* - 'vgcreate --clustered y' fails
* - 'vgcreate --shared' fails
* - 'vgcreate' (neither option) creates a local VG
*
* 2. Using clvmd.
* ------------------------------------------------
* lvm.conf:
* global/use_lvmlockd = 0
* global/locking_type = 3
*
* - locking through clvmd is enabled (traditional clvm config)
* - clvmd is used
* - lvmlockd is not used
* - VGs with CLUSTERED set can be used
* - VGs with lockd type are ignored (requires lvmlockd)
* - vgcreate can create new VGs with CLUSTERED status flag
* - 'vgcreate --clustered y' works
* - 'vgcreate --shared' fails
* - 'vgcreate' (neither option) creates a clvm VG
*
* 3. Using lvmlockd.
* ------------------------------------------------
* lvm.conf:
* global/use_lvmlockd = 1
* global/locking_type = 1
*
* - locking through lvmlockd is enabled
* - clvmd is not used
* - lvmlockd is used
* - VGs with CLUSTERED set are ignored (requires clvmd)
* - VGs with lockd type can be used
tools: Add support for "idm" lock type This patch is to update the comment and code to support "idm" lock type which is used for LVM toolkit. Signed-off-by: Leo Yan <leo.yan@linaro.org>
2021-05-07 05:25:16 +03:00
* - vgcreate can create new VGs with lock_type sanlock, dlm or idm
Add lvmlockd
2015-03-05 23:00:44 +03:00
* - 'vgcreate --clustered y' fails
* - 'vgcreate --shared' works
* - 'vgcreate' (neither option) creates a local VG
*/
use_lvmlockd = find_config_tree_bool(cmd, global_use_lvmlockd_CFG, NULL);
if (arg_is_set(cmd, locktype_ARG)) {
lock_type = arg_str_value(cmd, locktype_ARG, "");
vgcreate: allow both --shared and --lock-type options Using --lock-type sanlock|dlm implies --shared. Using --shared selects lock type sanlock|dlm (by choosing the one that's running.) Using both --shared and --lock-type sanlock|dlm should also be allowed (--shared is just redundant information.)
2015-10-08 18:14:33 +03:00
if (arg_is_set(cmd, shared_ARG) && !is_lockd_type(lock_type)) {
tools: Add support for "idm" lock type This patch is to update the comment and code to support "idm" lock type which is used for LVM toolkit. Signed-off-by: Leo Yan <leo.yan@linaro.org>
2021-05-07 05:25:16 +03:00
log_error("The --shared option requires lock type sanlock, dlm or idm.");
vgcreate: allow both --shared and --lock-type options Using --lock-type sanlock|dlm implies --shared. Using --shared selects lock type sanlock|dlm (by choosing the one that's running.) Using both --shared and --lock-type sanlock|dlm should also be allowed (--shared is just redundant information.)
2015-10-08 18:14:33 +03:00
return 0;
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
} else if (arg_is_set(cmd, shared_ARG)) {
vgcreate: improve error message for multiple lock managers If 'vgcreate --shared' finds both sanlock and dlm are running, print a more accurate error message: "Found multiple lock managers, select one with --lock-type." When neither is running, we still print: "Failed to detect a running lock manager to select lock type."
2015-10-08 18:38:35 +03:00
int found_multiple = 0;
Add lvmlockd
2015-03-05 23:00:44 +03:00
if (use_lvmlockd) {
vgcreate: improve error message for multiple lock managers If 'vgcreate --shared' finds both sanlock and dlm are running, print a more accurate error message: "Found multiple lock managers, select one with --lock-type." When neither is running, we still print: "Failed to detect a running lock manager to select lock type."
2015-10-08 18:38:35 +03:00
if (!(lock_type = lockd_running_lock_type(cmd, &found_multiple))) {
if (found_multiple)
log_error("Found multiple lock managers, select one with --lock-type.");
else
log_error("Failed to detect a running lock manager to select lock type.");
Add lvmlockd
2015-03-05 23:00:44 +03:00
return 0;
}
} else {
lvmlockd: update error message refer specifically to the "use_lvmlockd" setting in lvm.conf
2021-09-24 23:39:36 +03:00
log_error("Using a shared lock type requires lvmlockd (lvm.conf use_lvmlockd.)");
Add lvmlockd
2015-03-05 23:00:44 +03:00
return 0;
}
} else {
Remove clvmd and associated code More code reduction and simplification can follow.
2018-06-05 18:47:01 +03:00
lock_type = "none";
Add lvmlockd
2015-03-05 23:00:44 +03:00
}
/*
* Check that the lock_type is recognized, and is being
* used with the correct lvm.conf settings.
*/
lock_type_num = get_lock_type_from_string(lock_type);
switch (lock_type_num) {
case LOCK_TYPE_INVALID:
Remove clvmd and associated code More code reduction and simplification can follow.
2018-06-05 18:47:01 +03:00
case LOCK_TYPE_CLVM:
Add lvmlockd
2015-03-05 23:00:44 +03:00
log_error("lock_type %s is invalid", lock_type);
return 0;
case LOCK_TYPE_SANLOCK:
case LOCK_TYPE_DLM:
tools: Add support for "idm" lock type This patch is to update the comment and code to support "idm" lock type which is used for LVM toolkit. Signed-off-by: Leo Yan <leo.yan@linaro.org>
2021-05-07 05:25:16 +03:00
case LOCK_TYPE_IDM:
Add lvmlockd
2015-03-05 23:00:44 +03:00
if (!use_lvmlockd) {
lockd: fix error cases when built without lvmlockd When lvm is built without lvmlockd support, vgcreate using a shared lock type would succeed and create a local VG (the --shared option was effectively ignored). Make it fail. Fix the same issue when using vgchange to change a VG to a shared lock type. Make the error messages consistent.
2015-07-16 23:12:07 +03:00
log_error("Using a shared lock type requires lvmlockd.");
Add lvmlockd
2015-03-05 23:00:44 +03:00
return 0;
}
break;
case LOCK_TYPE_NONE:
break;
};
/*
* The vg is not owned by one host/system_id.
* Locking coordinates access from multiple hosts.
*/
Remove clvmd and associated code More code reduction and simplification can follow.
2018-06-05 18:47:01 +03:00
if (lock_type_num == LOCK_TYPE_DLM || lock_type_num == LOCK_TYPE_SANLOCK)
Add lvmlockd
2015-03-05 23:00:44 +03:00
vp_new->system_id = NULL;
vp_new->lock_type = lock_type;
log_debug("Setting lock_type to %s", vp_new->lock_type);
cleanup: swap return values Use lvm standard return code for success/fail 1/0.
2012-10-16 12:07:27 +04:00
return 1;
Allow vgcreate options as input to vgsplit when new vg is split destination.
2008-01-15 00:07:58 +03:00
}
Fix vgrename using UUID in case there are VGs with the same name.
2008-12-19 17:22:48 +03:00
tools: add common lv_change_activate Move common code for changing activation state from vgchange and lvchange to one function. Fix the order of checks - so we always implicitelly activate snapshots and thin volumes in exclusive mode, and we do not allow local deactivation for them.
2013-04-11 15:51:08 +04:00
/* Shared code for changing activation state for vgchange/lvchange */
int lv_change_activate(struct cmd_context *cmd, struct logical_volume *lv,
activation_change_t activate)
{
thin: activation of merging thin snapshot For merging thin snapshot we have to do couple extra checks before we allow this operation. We pretend thin-snapshot and thin-origin are tied together and we have to properly maintain locking.
2013-11-30 00:25:58 +04:00
int r = 1;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
int integrity_recalculate;
snapshot: Don't deactivate fictional snapshot LV. Commit 971ab733b74e0ffecc3f9f60af48628cd3fba1db ("thin: activation of merging thin snapshot") also added an incorrect deactivation attempt for non-thin LVs: find_snapshot(lv)->lv is not designed to be activated and any attempt to deactivate it is incorrect.
2016-04-14 22:48:28 +03:00
struct logical_volume *snapshot_lv;
thin: activation of merging thin snapshot For merging thin snapshot we have to do couple extra checks before we allow this operation. We pretend thin-snapshot and thin-origin are tied together and we have to properly maintain locking.
2013-11-30 00:25:58 +04:00
cache: allow deactivation of empty pool Tool will use internal activation of unused cache pool to clear metadata area before next use of cache-pool. So allow to deactivation unused pool in case some error case happend and we were not able to deactivation pool right after metadata wipe.
2014-11-02 19:48:21 +03:00
if (lv_is_cache_pool(lv)) {
if (is_change_activating(activate)) {
log_verbose("Skipping activation of cache pool %s.",
display_lvname(lv));
return 1;
}
if (!dm_list_empty(&lv->segs_using_this_lv)) {
log_verbose("Skipping deactivation of used cache pool %s.",
display_lvname(lv));
return 1;
}
/*
* Allow to pass only deactivation of unused cache pool.
* Useful only for recovery of failed zeroing of metadata LV.
*/
}
thin: activation of merging thin snapshot For merging thin snapshot we have to do couple extra checks before we allow this operation. We pretend thin-snapshot and thin-origin are tied together and we have to properly maintain locking.
2013-11-30 00:25:58 +04:00
if (lv_is_merging_origin(lv)) {
/*
* For merging origin, its snapshot must be inactive.
* If it's still active and cannot be deactivated
* activation or deactivation of origin fails!
*
* When origin is deactivated and merging snapshot is thin
* it allows to deactivate origin, but still report error,
* since the thin snapshot remains active.
*
* User could retry to deactivate it with another
* deactivation of origin, which is the only visible LV
*/
snapshot: Don't deactivate fictional snapshot LV. Commit 971ab733b74e0ffecc3f9f60af48628cd3fba1db ("thin: activation of merging thin snapshot") also added an incorrect deactivation attempt for non-thin LVs: find_snapshot(lv)->lv is not designed to be activated and any attempt to deactivate it is incorrect.
2016-04-14 22:48:28 +03:00
snapshot_lv = find_snapshot(lv)->lv;
if (lv_is_thin_type(snapshot_lv) && !deactivate_lv(cmd, snapshot_lv)) {
cleanup: use is_change_activating Use a single inline function to detect activation/deactivation
2014-02-18 23:52:17 +04:00
if (is_change_activating(activate)) {
debug: use display_lvname
2016-04-18 12:04:06 +03:00
log_error("Refusing to activate merging volume %s while "
"snapshot volume %s is still active.",
display_lvname(lv), display_lvname(snapshot_lv));
thin: activation of merging thin snapshot For merging thin snapshot we have to do couple extra checks before we allow this operation. We pretend thin-snapshot and thin-origin are tied together and we have to properly maintain locking.
2013-11-30 00:25:58 +04:00
return 0;
}
debug: use display_lvname
2016-04-18 12:04:06 +03:00
log_error("Cannot fully deactivate merging origin volume %s while "
"snapshot volume %s is still active.",
display_lvname(lv), display_lvname(snapshot_lv));
thin: activation of merging thin snapshot For merging thin snapshot we have to do couple extra checks before we allow this operation. We pretend thin-snapshot and thin-origin are tied together and we have to properly maintain locking.
2013-11-30 00:25:58 +04:00
r = 0; /* and continue to deactivate origin... */
}
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (is_change_activating(activate) &&
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
lvmcache_has_duplicate_devs() &&
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
vg_has_duplicate_pvs(lv->vg) &&
!find_config_tree_bool(cmd, devices_allow_changes_with_duplicate_pvs_CFG, NULL)) {
log_error("Cannot activate LVs in VG %s while PVs appear on duplicate devices.",
lv->vg->name);
return 0;
}
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
if ((integrity_recalculate = lv_has_integrity_recalculate_metadata(lv))) {
/* Don't want pvscan to write VG while running from systemd service. */
if (!strcmp(cmd->name, "pvscan")) {
log_error("Cannot activate uninitialized integrity LV %s from pvscan.",
display_lvname(lv));
return 0;
}
if (vg_is_shared(lv->vg)) {
uint32_t lockd_state = 0;
if (!lockd_vg(cmd, lv->vg->name, "ex", 0, &lockd_state)) {
log_error("Cannot activate uninitialized integrity LV %s without lock.",
display_lvname(lv));
return 0;
}
}
}
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (!lv_active_change(cmd, lv, activate))
lv: add lv_active_change Make a separate /lib function for the change of activation state of the LV. (in release update)
2013-04-29 16:04:38 +04:00
return_0;
tools: add common lv_change_activate Move common code for changing activation state from vgchange and lvchange to one function. Fix the order of checks - so we always implicitelly activate snapshots and thin volumes in exclusive mode, and we do not allow local deactivation for them.
2013-04-11 15:51:08 +04:00
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
/* Write VG metadata to clear the integrity recalculate flag. */
if (integrity_recalculate && lv_is_active(lv)) {
log_print_unless_silent("Updating VG to complete initialization of integrity LV %s.",
display_lvname(lv));
lv_clear_integrity_recalculate_metadata(lv);
}
pvscan: add options listlvs listvg checkcomplete pvscan --cache <dev> . read only dev . create online file for dev pvscan --listvg <dev> . read only dev . list VG using dev pvscan --listlvs <dev> . read only dev . list VG using dev . list LVs using dev pvscan --cache --listvg [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . [check online files and report if VG is complete] pvscan --cache --listlvs [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . list LVs using dev . [check online files and report if VG is complete] . [check online files and report if LVs are complete] [--vgonline] can be used with --checkcomplete, to enable use of a vg online file. This results in only the first pvscan command to see the complete VG to report 'VG complete', and others will report 'VG finished'. This allows the caller to easily run a single activation of the VG. [--udevoutput] can be used with --cache --listvg --checkcomplete, to enable an output mode that prints LVM_VG_NAME_COMPLETE='vgname' that a udev rule can import, and prevents other output from the command (other output causes udev to ignore the command.) The list of complete LVs is meant to be passed to lvchange -aay, or the complete VG used with vgchange -aay. When --checkcomplete is used, lvm assumes that that the output will be used to trigger event-based autoactivation, so the pvscan does nothing if event_activation=0 and --checkcomplete is used. Example of listlvs ------------------ $ lvs -a vg -olvname,devices LV Devices lv_a /dev/loop0(0) lv_ab /dev/loop0(1),/dev/loop1(1) lv_abc /dev/loop0(3),/dev/loop1(3),/dev/loop2(1) lv_b /dev/loop1(0) lv_c /dev/loop2(0) $ pvscan --cache --listlvs --checkcomplete /dev/loop0 pvscan[35680] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete LV vg/lv_a complete LV vg/lv_ab incomplete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop1 pvscan[35681] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete LV vg/lv_b complete LV vg/lv_ab complete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop2 pvscan[35682] PV /dev/loop2 online, VG vg is complete. VG vg complete LV vg/lv_c complete LV vg/lv_abc complete Example of listvg ----------------- $ pvscan --cache --listvg --checkcomplete /dev/loop0 pvscan[35684] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop1 pvscan[35685] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop2 pvscan[35686] PV /dev/loop2 online, VG vg is complete. VG vg complete
2020-12-09 19:59:40 +03:00
/*
* When LVs are deactivated, then autoactivation of the VG is
* "re-armed" by removing the vg online file. So, after deactivation
* of LVs, if PVs are disconnected and reconnected again, event
* activation will trigger autoactivation again. This secondary
* autoactivation is somewhat different from, and not as important as
* the initial autoactivation during system startup. The secondary
* autoactivation will happen to a VG on a running system and may be
* mixing with user commands, so the end result is unpredictable.
*
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
* It's possible that we might want a config setting for usersto
pvscan: add options listlvs listvg checkcomplete pvscan --cache <dev> . read only dev . create online file for dev pvscan --listvg <dev> . read only dev . list VG using dev pvscan --listlvs <dev> . read only dev . list VG using dev . list LVs using dev pvscan --cache --listvg [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . [check online files and report if VG is complete] pvscan --cache --listlvs [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . list LVs using dev . [check online files and report if VG is complete] . [check online files and report if LVs are complete] [--vgonline] can be used with --checkcomplete, to enable use of a vg online file. This results in only the first pvscan command to see the complete VG to report 'VG complete', and others will report 'VG finished'. This allows the caller to easily run a single activation of the VG. [--udevoutput] can be used with --cache --listvg --checkcomplete, to enable an output mode that prints LVM_VG_NAME_COMPLETE='vgname' that a udev rule can import, and prevents other output from the command (other output causes udev to ignore the command.) The list of complete LVs is meant to be passed to lvchange -aay, or the complete VG used with vgchange -aay. When --checkcomplete is used, lvm assumes that that the output will be used to trigger event-based autoactivation, so the pvscan does nothing if event_activation=0 and --checkcomplete is used. Example of listlvs ------------------ $ lvs -a vg -olvname,devices LV Devices lv_a /dev/loop0(0) lv_ab /dev/loop0(1),/dev/loop1(1) lv_abc /dev/loop0(3),/dev/loop1(3),/dev/loop2(1) lv_b /dev/loop1(0) lv_c /dev/loop2(0) $ pvscan --cache --listlvs --checkcomplete /dev/loop0 pvscan[35680] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete LV vg/lv_a complete LV vg/lv_ab incomplete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop1 pvscan[35681] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete LV vg/lv_b complete LV vg/lv_ab complete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop2 pvscan[35682] PV /dev/loop2 online, VG vg is complete. VG vg complete LV vg/lv_c complete LV vg/lv_abc complete Example of listvg ----------------- $ pvscan --cache --listvg --checkcomplete /dev/loop0 pvscan[35684] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop1 pvscan[35685] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop2 pvscan[35686] PV /dev/loop2 online, VG vg is complete. VG vg complete
2020-12-09 19:59:40 +03:00
* disable secondary autoactivations. Once a system is up, the
* user may want to take charge of activation changes to the VG
* and not have the system autoactivation interfere.
*/
toollib: avoid repeated remove of online vg Call just once unlink after every deactivation of LV from VG.
2021-12-17 15:18:56 +03:00
if (!is_change_activating(activate) && cmd->event_activation &&
!cmd->online_vg_file_removed) {
cmd->online_vg_file_removed = 1;
pvscan: add options listlvs listvg checkcomplete pvscan --cache <dev> . read only dev . create online file for dev pvscan --listvg <dev> . read only dev . list VG using dev pvscan --listlvs <dev> . read only dev . list VG using dev . list LVs using dev pvscan --cache --listvg [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . [check online files and report if VG is complete] pvscan --cache --listlvs [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . list LVs using dev . [check online files and report if VG is complete] . [check online files and report if LVs are complete] [--vgonline] can be used with --checkcomplete, to enable use of a vg online file. This results in only the first pvscan command to see the complete VG to report 'VG complete', and others will report 'VG finished'. This allows the caller to easily run a single activation of the VG. [--udevoutput] can be used with --cache --listvg --checkcomplete, to enable an output mode that prints LVM_VG_NAME_COMPLETE='vgname' that a udev rule can import, and prevents other output from the command (other output causes udev to ignore the command.) The list of complete LVs is meant to be passed to lvchange -aay, or the complete VG used with vgchange -aay. When --checkcomplete is used, lvm assumes that that the output will be used to trigger event-based autoactivation, so the pvscan does nothing if event_activation=0 and --checkcomplete is used. Example of listlvs ------------------ $ lvs -a vg -olvname,devices LV Devices lv_a /dev/loop0(0) lv_ab /dev/loop0(1),/dev/loop1(1) lv_abc /dev/loop0(3),/dev/loop1(3),/dev/loop2(1) lv_b /dev/loop1(0) lv_c /dev/loop2(0) $ pvscan --cache --listlvs --checkcomplete /dev/loop0 pvscan[35680] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete LV vg/lv_a complete LV vg/lv_ab incomplete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop1 pvscan[35681] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete LV vg/lv_b complete LV vg/lv_ab complete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop2 pvscan[35682] PV /dev/loop2 online, VG vg is complete. VG vg complete LV vg/lv_c complete LV vg/lv_abc complete Example of listvg ----------------- $ pvscan --cache --listvg --checkcomplete /dev/loop0 pvscan[35684] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop1 pvscan[35685] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop2 pvscan[35686] PV /dev/loop2 online, VG vg is complete. VG vg complete
2020-12-09 19:59:40 +03:00
online_vg_file_remove(lv->vg->name);
toollib: avoid repeated remove of online vg Call just once unlink after every deactivation of LV from VG.
2021-12-17 15:18:56 +03:00
}
pvscan: add options listlvs listvg checkcomplete pvscan --cache <dev> . read only dev . create online file for dev pvscan --listvg <dev> . read only dev . list VG using dev pvscan --listlvs <dev> . read only dev . list VG using dev . list LVs using dev pvscan --cache --listvg [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . [check online files and report if VG is complete] pvscan --cache --listlvs [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . list LVs using dev . [check online files and report if VG is complete] . [check online files and report if LVs are complete] [--vgonline] can be used with --checkcomplete, to enable use of a vg online file. This results in only the first pvscan command to see the complete VG to report 'VG complete', and others will report 'VG finished'. This allows the caller to easily run a single activation of the VG. [--udevoutput] can be used with --cache --listvg --checkcomplete, to enable an output mode that prints LVM_VG_NAME_COMPLETE='vgname' that a udev rule can import, and prevents other output from the command (other output causes udev to ignore the command.) The list of complete LVs is meant to be passed to lvchange -aay, or the complete VG used with vgchange -aay. When --checkcomplete is used, lvm assumes that that the output will be used to trigger event-based autoactivation, so the pvscan does nothing if event_activation=0 and --checkcomplete is used. Example of listlvs ------------------ $ lvs -a vg -olvname,devices LV Devices lv_a /dev/loop0(0) lv_ab /dev/loop0(1),/dev/loop1(1) lv_abc /dev/loop0(3),/dev/loop1(3),/dev/loop2(1) lv_b /dev/loop1(0) lv_c /dev/loop2(0) $ pvscan --cache --listlvs --checkcomplete /dev/loop0 pvscan[35680] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete LV vg/lv_a complete LV vg/lv_ab incomplete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop1 pvscan[35681] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete LV vg/lv_b complete LV vg/lv_ab complete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop2 pvscan[35682] PV /dev/loop2 online, VG vg is complete. VG vg complete LV vg/lv_c complete LV vg/lv_abc complete Example of listvg ----------------- $ pvscan --cache --listvg --checkcomplete /dev/loop0 pvscan[35684] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop1 pvscan[35685] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop2 pvscan[35686] PV /dev/loop2 online, VG vg is complete. VG vg complete
2020-12-09 19:59:40 +03:00
dbus: add notification from commands When a command modifies a PV or VG, or changes the activation state of an LV, it will send a dbus notification when the command is finished. This can be enabled/disabled with a config setting.
2016-02-22 18:42:03 +03:00
set_lv_notify(lv->vg->cmd);
thin: activation of merging thin snapshot For merging thin snapshot we have to do couple extra checks before we allow this operation. We pretend thin-snapshot and thin-origin are tied together and we have to properly maintain locking.
2013-11-30 00:25:58 +04:00
return r;
tools: add common lv_change_activate Move common code for changing activation state from vgchange and lvchange to one function. Fix the order of checks - so we always implicitelly activate snapshots and thin volumes in exclusive mode, and we do not allow local deactivation for them.
2013-04-11 15:51:08 +04:00
}
Fix vgrename using UUID in case there are VGs with the same name.
2008-12-19 17:22:48 +03:00
int lv_refresh(struct cmd_context *cmd, struct logical_volume *lv)
{
lvchange: improve refresh for merging thin volume When running lvchange --refresh on merging thin volume, try to deactivate snapshot thinLV in case it's preventing startup of merge process.
2016-04-18 23:44:30 +03:00
struct logical_volume *snapshot_lv;
if (lv_is_merging_origin(lv)) {
snapshot_lv = find_snapshot(lv)->lv;
if (lv_is_thin_type(snapshot_lv) && !deactivate_lv(cmd, snapshot_lv))
log_print_unless_silent("Delaying merge for origin volume %s since "
"snapshot volume %s is still active.",
display_lvname(lv), display_lvname(snapshot_lv));
}
cleanup: drop cmd and constify lv for lv_refresh_suspend_resume() Like with most other lv_manip* functions take just LV arg and get cmd from embeded pointer when needed.
2016-05-20 11:55:05 +03:00
if (!lv_refresh_suspend_resume(lv))
lv_refresh: move the bulk of the function into lib So that it can be used from other lib code.
2015-06-16 21:38:40 +03:00
return_0;
Add missing 'stack;' for all suspend_lv and resume_lv callers. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2010-01-06 00:07:31 +03:00
Start background polling of merging stores on: - lvchange -ay or vgchange -ay. - lvchange --refresh or vgchange --refresh.
2010-01-13 04:50:34 +03:00
/*
* check if snapshot merge should be polled
* - unfortunately: even though the dev_manager will clear
* the lv's merge attributes if a merge is not possible;
* it is clearing a different instance of the lv (as
* retrieved with lv_from_lvid)
* - fortunately: polldaemon will immediately shutdown if the
* origin doesn't have a status with a snapshot percentage
*/
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (background_polling() && lv_is_merging_origin(lv) && lv_is_active(lv))
Start background polling of merging stores on: - lvchange -ay or vgchange -ay. - lvchange --refresh or vgchange --refresh.
2010-01-13 04:50:34 +03:00
lv_spawn_background_polling(cmd, lv);
refresh: print error message with failing lv name If there is suspend/resume error, print error message with lv name. Drop goto.
2013-11-29 14:10:41 +04:00
return 1;
Fix vgrename using UUID in case there are VGs with the same name.
2008-12-19 17:22:48 +03:00
}
Add "--refresh" functionality to vgchange and vgmknodes.
2008-12-22 12:00:51 +03:00
int vg_refresh_visible(struct cmd_context *cmd, struct volume_group *vg)
{
struct lv_list *lvl;
int r = 1;
Cleanup comment and some whitespace.
2009-10-06 20:00:38 +04:00
Support break for vgchange and vgrefresh operation Allow to break some lengthy vgchange and vgrefresh operation.
2011-09-07 12:41:47 +04:00
sigint_allow();
dm_list_iterate_items(lvl, &vg->lvs) {
sigint: improve logic on for sigint reaction Fix and improve handling on sigint. Always check for signal presence *before* calling of command, so it will not call the command when break was hit. If the command has been finished succesfully there is no problem to mark the command ok and not report interrupt at all. Fix cuple related stack; reports and assignments.
2013-07-01 18:30:12 +04:00
if (sigint_caught()) {
r = 0;
stack;
break;
}
Support break for vgchange and vgrefresh operation Allow to break some lengthy vgchange and vgrefresh operation.
2011-09-07 12:41:47 +04:00
lv/vgchange: when refreshing whole vg skip snapshot When refreshing all LVs in a VG, skip processing of thick snapshots, since they will be refreshed through its origin LV. Should reduce some unnecessary ioctl().
2023-02-01 00:48:43 +03:00
if (lv_is_visible(lvl->lv) &&
!(lv_is_cow(lvl->lv) && !lv_is_virtual_origin(origin_from_cow(lvl->lv))) &&
!lv_refresh(cmd, lvl->lv)) {
sigint: improve logic on for sigint reaction Fix and improve handling on sigint. Always check for signal presence *before* calling of command, so it will not call the command when break was hit. If the command has been finished succesfully there is no problem to mark the command ok and not report interrupt at all. Fix cuple related stack; reports and assignments.
2013-07-01 18:30:12 +04:00
r = 0;
stack;
}
Support break for vgchange and vgrefresh operation Allow to break some lengthy vgchange and vgrefresh operation.
2011-09-07 12:41:47 +04:00
}
sigint_restore();
Cleanup comment and some whitespace.
2009-10-06 20:00:38 +04:00
Add "--refresh" functionality to vgchange and vgmknodes.
2008-12-22 12:00:51 +03:00
return r;
}
Don't attempt to restart pvmoves when deactivating LVs in vgchange. Restart lvconverts in vgchange by sharing lv_spawn_background_polling.
2009-09-30 00:22:35 +04:00
void lv_spawn_background_polling(struct cmd_context *cmd,
struct logical_volume *lv)
{
const char *pvname;
toollib: code cleanup in lv_spawn_background_polling we're going to extract parameters from lv_mirr later with code refactoring of polldaemon
2015-04-29 17:25:50 +03:00
const struct logical_volume *lv_mirr = NULL;
Don't attempt to restart pvmoves when deactivating LVs in vgchange. Restart lvconverts in vgchange by sharing lv_spawn_background_polling.
2009-09-30 00:22:35 +04:00
tools: missing sync after deactivation Caching of DM states optimisation revealed some missing synchronisation points.
2022-01-28 19:42:04 +03:00
/* Ensure there is nothing waiting on cookie */
if (!sync_local_dev_names(cmd))
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Failed to sync local dev names.");
tools: missing sync after deactivation Caching of DM states optimisation revealed some missing synchronisation points.
2022-01-28 19:42:04 +03:00
toollib: code cleanup in lv_spawn_background_polling we're going to extract parameters from lv_mirr later with code refactoring of polldaemon
2015-04-29 17:25:50 +03:00
if (lv_is_pvmove(lv))
lv_mirr = lv;
else if (lv_is_locked(lv))
lv_mirr = find_pvmove_lv_in_lv(lv);
if (lv_mirr &&
(pvname = get_pvmove_pvname_from_lv_mirr(lv_mirr))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_verbose("Spawning background pvmove process for %s.",
Don't attempt to restart pvmoves when deactivating LVs in vgchange. Restart lvconverts in vgchange by sharing lv_spawn_background_polling.
2009-09-30 00:22:35 +04:00
pvname);
polldaemon: refactor polling interfaces Routines responsible for polling of in-progress pvmove, snapshot merge or mirror conversion each used custom lookup functions to find vg and lv involved in polling. Especially pvmove used pvname to lookup pvmove in-progress. The future lvmpolld will poll each operation by vg/lv name (internally by lvid). Also there're plans to make pvmove able to move non-overlaping ranges of extents instead of single PVs as of now. This would also require to identify the opertion in different manner. The poll_operation_id structure together with daemon_parms structure they identify unambiguously the polling task.
2015-04-10 15:08:19 +03:00
pvmove_poll(cmd, pvname, lv_mirr->lvid.s, lv_mirr->vg->name, lv_mirr->name, 1);
Don't attempt to restart pvmoves when deactivating LVs in vgchange. Restart lvconverts in vgchange by sharing lv_spawn_background_polling.
2009-09-30 00:22:35 +04:00
}
cleanup: Use lv_is_ macros. Use lv_is_* macros throughout the code base, introducing lv_is_pvmove, lv_is_locked, lv_is_converting and lv_is_merging. lv_is_mirror_type no longer includes pvmove.
2014-09-16 00:33:53 +04:00
if (lv_is_converting(lv) || lv_is_merging(lv)) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_verbose("Spawning background lvconvert process for %s.",
toollib: code cleanup in lv_spawn_background_polling we're going to extract parameters from lv_mirr later with code refactoring of polldaemon
2015-04-29 17:25:50 +03:00
lv->name);
Don't attempt to restart pvmoves when deactivating LVs in vgchange. Restart lvconverts in vgchange by sharing lv_spawn_background_polling.
2009-09-30 00:22:35 +04:00
lvconvert_poll(cmd, lv, 1);
}
}
Move pvcreate_validate_params into toollib to allow calling from mutiple tools. For implicit pvcreate support, we need to call this from vgcreate and vgextend, so move it into toollib.
2009-10-06 00:03:54 +04:00
Improve activation monitoring option processing . Add "monitoring" option to "activation" section of lvm.conf . Have clvmd consult the lvm.conf "activation/monitoring" too. . Introduce toollib.c:get_activation_monitoring_mode(). . Error out when both --monitor and --ignoremonitoring are provided. . Add --monitor and --ignoremonitoring support to lvcreate. Update lvcreate man page accordingly. . Clarify that '--monitor' controls the start and stop of monitoring in the {vg,lv}change man pages. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2010-03-24 01:30:18 +03:00
int get_activation_monitoring_mode(struct cmd_context *cmd,
int *monitoring_mode)
{
*monitoring_mode = DEFAULT_DMEVENTD_MONITOR;
tools: Use arg_is_set instead of arg_count.
2016-06-22 00:24:52 +03:00
if (arg_is_set(cmd, monitor_ARG) &&
(arg_is_set(cmd, ignoremonitoring_ARG) ||
arg_is_set(cmd, sysinit_ARG))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("--ignoremonitoring or --sysinit option not allowed with --monitor option.");
Improve activation monitoring option processing . Add "monitoring" option to "activation" section of lvm.conf . Have clvmd consult the lvm.conf "activation/monitoring" too. . Introduce toollib.c:get_activation_monitoring_mode(). . Error out when both --monitor and --ignoremonitoring are provided. . Add --monitor and --ignoremonitoring support to lvcreate. Update lvcreate man page accordingly. . Clarify that '--monitor' controls the start and stop of monitoring in the {vg,lv}change man pages. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2010-03-24 01:30:18 +03:00
return 0;
}
tools: Use arg_is_set instead of arg_count.
2016-06-22 00:24:52 +03:00
if (arg_is_set(cmd, monitor_ARG))
Improve activation monitoring option processing . Add "monitoring" option to "activation" section of lvm.conf . Have clvmd consult the lvm.conf "activation/monitoring" too. . Introduce toollib.c:get_activation_monitoring_mode(). . Error out when both --monitor and --ignoremonitoring are provided. . Add --monitor and --ignoremonitoring support to lvcreate. Update lvcreate man page accordingly. . Clarify that '--monitor' controls the start and stop of monitoring in the {vg,lv}change man pages. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2010-03-24 01:30:18 +03:00
*monitoring_mode = arg_int_value(cmd, monitor_ARG,
DEFAULT_DMEVENTD_MONITOR);
tools: Use arg_is_set instead of arg_count.
2016-06-22 00:24:52 +03:00
else if (is_static() || arg_is_set(cmd, ignoremonitoring_ARG) ||
arg_is_set(cmd, sysinit_ARG) ||
config: add profile arg to find_config_tree_bool
2013-06-25 14:31:53 +04:00
!find_config_tree_bool(cmd, activation_monitoring_CFG, NULL))
Improve activation monitoring option processing . Add "monitoring" option to "activation" section of lvm.conf . Have clvmd consult the lvm.conf "activation/monitoring" too. . Introduce toollib.c:get_activation_monitoring_mode(). . Error out when both --monitor and --ignoremonitoring are provided. . Add --monitor and --ignoremonitoring support to lvcreate. Update lvcreate man page accordingly. . Clarify that '--monitor' controls the start and stop of monitoring in the {vg,lv}change man pages. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2010-03-24 01:30:18 +03:00
*monitoring_mode = DMEVENTD_MONITOR_IGNORE;
Do not allow {vg|lv}change --ignoremonitoring if on clustered VG. clvmd does not propagate DMEVENTD_MONITOR_IGNORE. Update get_activation_monitoring_mode() to check if the VG that the LV is being activated in is clustered. If so, skip it. Any get_activation_monitoring_mode() error will cause the associated LV (or VG) to be skipped during activation. Both vgchange_single() and lvchange_single(), which call get_activation_monitoring_mode(), are called by their respective process_each_..() method.
2010-03-29 20:09:40 +04:00
Improve activation monitoring option processing . Add "monitoring" option to "activation" section of lvm.conf . Have clvmd consult the lvm.conf "activation/monitoring" too. . Introduce toollib.c:get_activation_monitoring_mode(). . Error out when both --monitor and --ignoremonitoring are provided. . Add --monitor and --ignoremonitoring support to lvcreate. Update lvcreate man page accordingly. . Clarify that '--monitor' controls the start and stop of monitoring in the {vg,lv}change man pages. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2010-03-24 01:30:18 +03:00
return 1;
}
Add --stripes to lvconvert too.
2010-04-13 05:54:32 +04:00
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
/*
* Read pool options from cmdline
*/
thin: make selected thinp settings profilable These settins are customizable by profiles: allocation/thin_pool_zero allocation/thin_pool_discards allocation/thin_pool_chunk_size activation/thin_pool_autoextend_threshold activation/thin_pool_autoextend_percent
2013-06-27 13:22:02 +04:00
int get_pool_params(struct cmd_context *cmd,
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
const struct segment_type *segtype,
thin_pool: introduce --pooldatavdo Introducing new arg --pooldatavdo y|n
2023-12-07 21:17:35 +03:00
int *pool_data_vdo,
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
uint64_t *pool_metadata_size,
int *pool_metadata_spare,
thin: add common pool functions Move common functions for lvcreate and lvconvert. get_pool_params() - read thin pool args. update_pool_params() - updates/validates some thin args. It is getting complicated and even few more things will be implemented, so to avoid reimplementing things differently in lvcreate and lvconvert code has been splitted into 2 common functions that allow some future extension.
2012-11-15 17:48:32 +04:00
uint32_t *chunk_size,
thin_discards_t *discards,
thin: add new ZERO/DISCARDS_UNSELECTED To more easily recognize unselected state from select '0' state add new 'THIN_ZERO_UNSELECTED' enum. Same applies to THIN_DISCARDS_UNSELECTED. For those we no longer need to use PASS_ARG_ZERO or PASS_ARG_DISCARDS.
2017-03-03 22:46:13 +03:00
thin_zero_t *zero_new_blocks)
thin: add common pool functions Move common functions for lvcreate and lvconvert. get_pool_params() - read thin pool args. update_pool_params() - updates/validates some thin args. It is getting complicated and even few more things will be implemented, so to avoid reimplementing things differently in lvcreate and lvconvert code has been splitted into 2 common functions that allow some future extension.
2012-11-15 17:48:32 +04:00
{
thin_pool: introduce --pooldatavdo Introducing new arg --pooldatavdo y|n
2023-12-07 21:17:35 +03:00
if ((*pool_data_vdo = arg_int_value(cmd, pooldatavdo_ARG, 0))) {
if (!(segtype = get_segtype_from_string(cmd, SEG_TYPE_NAME_VDO)))
return_0;
if (activation() && segtype->ops->target_present) {
if (!segtype->ops->target_present(cmd, NULL, NULL)) {
log_error("%s: Required device-mapper target(s) not detected in your kernel.",
segtype->name);
return_0;
}
}
}
if (segtype_is_thin_pool(segtype) || segtype_is_thin(segtype) || *pool_data_vdo) {
cleanup: use arg_is_set
2014-10-31 13:41:03 +03:00
if (arg_is_set(cmd, zero_ARG)) {
thin: add new ZERO/DISCARDS_UNSELECTED To more easily recognize unselected state from select '0' state add new 'THIN_ZERO_UNSELECTED' enum. Same applies to THIN_DISCARDS_UNSELECTED. For those we no longer need to use PASS_ARG_ZERO or PASS_ARG_DISCARDS.
2017-03-03 22:46:13 +03:00
*zero_new_blocks = arg_int_value(cmd, zero_ARG, 0) ? THIN_ZERO_YES : THIN_ZERO_NO;
log_very_verbose("%s pool zeroing.",
(*zero_new_blocks == THIN_ZERO_YES) ? "Enabling" : "Disabling");
} else
*zero_new_blocks = THIN_ZERO_UNSELECTED;
cleanup: use arg_is_set
2014-10-31 13:41:03 +03:00
if (arg_is_set(cmd, discards_ARG)) {
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
*discards = (thin_discards_t) arg_uint_value(cmd, discards_ARG, 0);
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_very_verbose("Setting pool discards to %s.",
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
get_pool_discards_name(*discards));
thin: add new ZERO/DISCARDS_UNSELECTED To more easily recognize unselected state from select '0' state add new 'THIN_ZERO_UNSELECTED' enum. Same applies to THIN_DISCARDS_UNSELECTED. For those we no longer need to use PASS_ARG_ZERO or PASS_ARG_DISCARDS.
2017-03-03 22:46:13 +03:00
} else
*discards = THIN_DISCARDS_UNSELECTED;
thin: add common pool functions Move common functions for lvcreate and lvconvert. get_pool_params() - read thin pool args. update_pool_params() - updates/validates some thin args. It is getting complicated and even few more things will be implemented, so to avoid reimplementing things differently in lvcreate and lvconvert code has been splitted into 2 common functions that allow some future extension.
2012-11-15 17:48:32 +04:00
}
thin: support configurable thin pool defaults Configurable settings for thin pool create if they are not specified on command line. New supported lvm.conf options are: allocation/thin_pool_chunk_size allocation/thin_pool_discards allocation/thin_pool_zero
2012-11-26 14:20:13 +04:00
pool: validate sizes 0 size are not supported as well as negative.
2014-10-31 13:41:49 +03:00
if (arg_from_list_is_negative(cmd, "may not be negative",
chunksize_ARG,
pooldatasize_ARG,
poolmetadatasize_ARG,
-1))
return_0;
if (arg_from_list_is_zero(cmd, "may not be zero",
chunksize_ARG,
pooldatasize_ARG,
poolmetadatasize_ARG,
-1))
return_0;
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
pool: validate sizes 0 size are not supported as well as negative.
2014-10-31 13:41:49 +03:00
if (arg_is_set(cmd, chunksize_ARG)) {
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
*chunk_size = arg_uint_value(cmd, chunksize_ARG, 0);
toolib: early validation of chunk size Since we now have validate_pool_chunk_size() we could validate entered values directly prior openning vg.
2014-10-05 00:36:41 +04:00
if (!validate_pool_chunk_size(cmd, segtype, *chunk_size))
return_0;
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_very_verbose("Setting pool chunk size to %s.",
thin: support configurable thin pool defaults Configurable settings for thin pool create if they are not specified on command line. New supported lvm.conf options are: allocation/thin_pool_chunk_size allocation/thin_pool_discards allocation/thin_pool_zero
2012-11-26 14:20:13 +04:00
display_size(cmd, *chunk_size));
pool: rework handling of passed args As now we can properly recognize all paramerters for pool creation, we may drop PASS_ARG_ defines and rely on '_UNSELECTED' or 0 entries as being those without user given args. When setting are not given on command line - 'update' function fill them from profiles or configuration. For this 'profile' arg was needed to be passed around and since 'VG' itself is not needed, it's been all replaced with 'cmd, profile, extents_size' args.
2017-03-09 18:24:28 +03:00
} else
*chunk_size = 0;
thin: apply VG profile if creating a new thin pool When creating a new thin pool and there's no profile requested via "lvcreate --profile ...", inherit any VG profile if it's attached. Currently this applies to these settings: allocation/thin_pool_chunk_size allocation/thin_pool_discards allocation/thin_pool_zero
2013-08-06 13:42:40 +04:00
tools: Use arg_is_set instead of arg_count.
2016-06-22 00:24:52 +03:00
if (arg_is_set(cmd, poolmetadatasize_ARG)) {
if (arg_is_set(cmd, poolmetadata_ARG)) {
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
log_error("Please specify either metadata logical volume or its size.");
return 0;
}
lvconvert: update for thin a cache Major update of lvconvert code to handle cache and thin. related targets. Code tries to unify handling of cache and thin pools. Better supports lvm2 syntax: lvconvert --type cache --cachepool vg/pool vg/cache lvconvert --type thin --thinpool vg/pool vg/extorg lvconvert --type cache-pool vg/pool lvconvert --type thin-pool vg/pool as well as: lvconvert --cache --cachepool vg/pool vg/cache lvconvert --thin --thinpool vg/pool vg/extorg lvconvert --cachepool vg/pool lvconvert --thinpool vg/pool While catching much more command line errors. (Yet couple paths still needs more tests) Detects as much cmdline errors prior opening VG. Uses single lvconvert_name_params to convert LV names. Detects as much incompatibilies in VG prior prompting. Uses single prompt to confirm whole conversion. TODO: still the code needs fixes...
2014-07-11 14:15:23 +04:00
*pool_metadata_size = arg_uint64_value(cmd, poolmetadatasize_ARG,
UINT64_C(0));
pool: rework handling of passed args As now we can properly recognize all paramerters for pool creation, we may drop PASS_ARG_ defines and rely on '_UNSELECTED' or 0 entries as being those without user given args. When setting are not given on command line - 'update' function fill them from profiles or configuration. For this 'profile' arg was needed to be passed around and since 'VG' itself is not needed, it's been all replaced with 'cmd, profile, extents_size' args.
2017-03-09 18:24:28 +03:00
} else
*pool_metadata_size = 0;
/* TODO: default in lvm.conf and metadata profile ? */
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
*pool_metadata_spare = arg_int_value(cmd, poolmetadataspare_ARG,
DEFAULT_POOL_METADATA_SPARE);
thin: add common pool functions Move common functions for lvcreate and lvconvert. get_pool_params() - read thin pool args. update_pool_params() - updates/validates some thin args. It is getting complicated and even few more things will be implemented, so to avoid reimplementing things differently in lvcreate and lvconvert code has been splitted into 2 common functions that allow some future extension.
2012-11-15 17:48:32 +04:00
return 1;
}
Add --stripes to lvconvert too.
2010-04-13 05:54:32 +04:00
/*
* Generic stripe parameter checks.
*/
tools: Unify stripesize parameter validation. Move it all into get_stripe_params(). Some code paths missed --stripesize checks. E.g. lvcreate --type raid4 -i1
2016-07-30 04:05:50 +03:00
static int _validate_stripe_params(struct cmd_context *cmd, const struct segment_type *segtype,
uint32_t *stripes, uint32_t *stripe_size)
Add --stripes to lvconvert too.
2010-04-13 05:54:32 +04:00
{
toollib: improve stripes args reading Rewrite validation of stripes and stripe_size args into more readable sequential code. Extend reading of stripes & stripes_size args so it better knows defaults for types like striped raid. TODO: this should really be a value obtained for segtype structure and all the weird conditions and modification of stripes and stripe_size around lvm2 code should be dropped.
2017-11-27 12:26:35 +03:00
if (*stripes < 1 || *stripes > MAX_STRIPES) {
log_error("Number of stripes (%d) must be between %d and %d.",
*stripes, 1, MAX_STRIPES);
return 0;
}
tools: Unify stripesize parameter validation. Move it all into get_stripe_params(). Some code paths missed --stripesize checks. E.g. lvcreate --type raid4 -i1
2016-07-30 04:05:50 +03:00
toollib: improve stripes args reading Rewrite validation of stripes and stripe_size args into more readable sequential code. Extend reading of stripes & stripes_size args so it better knows defaults for types like striped raid. TODO: this should really be a value obtained for segtype structure and all the weird conditions and modification of stripes and stripe_size around lvm2 code should be dropped.
2017-11-27 12:26:35 +03:00
if (!segtype_supports_stripe_size(segtype)) {
if (*stripe_size) {
log_print_unless_silent("Ignoring stripesize argument for %s devices.",
segtype->name);
*stripe_size = 0;
}
} else if (*stripes == 1) {
tools: Suppress some unnecessary --stripesize warnings. https://bugzilla.redhat.com/1366745
2016-08-15 21:38:45 +03:00
if (*stripe_size) {
log_print_unless_silent("Ignoring stripesize argument with single stripe.");
*stripe_size = 0;
}
toollib: improve stripes args reading Rewrite validation of stripes and stripe_size args into more readable sequential code. Extend reading of stripes & stripes_size args so it better knows defaults for types like striped raid. TODO: this should really be a value obtained for segtype structure and all the weird conditions and modification of stripes and stripe_size around lvm2 code should be dropped.
2017-11-27 12:26:35 +03:00
} else {
tools: Unify stripesize parameter validation. Move it all into get_stripe_params(). Some code paths missed --stripesize checks. E.g. lvcreate --type raid4 -i1
2016-07-30 04:05:50 +03:00
if (!*stripe_size) {
*stripe_size = find_config_tree_int(cmd, metadata_stripesize_CFG, NULL) * 2;
log_print_unless_silent("Using default stripesize %s.",
display_size(cmd, (uint64_t) *stripe_size));
}
toollib: improve stripes args reading Rewrite validation of stripes and stripe_size args into more readable sequential code. Extend reading of stripes & stripes_size args so it better knows defaults for types like striped raid. TODO: this should really be a value obtained for segtype structure and all the weird conditions and modification of stripes and stripe_size around lvm2 code should be dropped.
2017-11-27 12:26:35 +03:00
if (*stripe_size > STRIPE_SIZE_LIMIT * 2) {
log_error("Stripe size cannot be larger than %s.",
display_size(cmd, (uint64_t) STRIPE_SIZE_LIMIT));
return 0;
} else if (*stripe_size < STRIPE_SIZE_MIN || !is_power_of_2(*stripe_size)) {
tools: Unify stripesize parameter validation. Move it all into get_stripe_params(). Some code paths missed --stripesize checks. E.g. lvcreate --type raid4 -i1
2016-07-30 04:05:50 +03:00
log_error("Invalid stripe size %s.",
display_size(cmd, (uint64_t) *stripe_size));
return 0;
}
Add --stripes to lvconvert too.
2010-04-13 05:54:32 +04:00
}
return 1;
}
/*
* The stripe size is limited by the size of a uint32_t, but since the
* value given by the user is doubled, and the final result must be a
* power of 2, we must divide UINT_MAX by four and add 1 (to round it
* up to the power of 2)
*/
toollib: Record whether or not stripes/stripe_size args supplied.
2016-08-19 15:51:43 +03:00
int get_stripe_params(struct cmd_context *cmd, const struct segment_type *segtype,
uint32_t *stripes, uint32_t *stripe_size,
unsigned *stripes_supplied, unsigned *stripe_size_supplied)
Add --stripes to lvconvert too.
2010-04-13 05:54:32 +04:00
{
/* stripes_long_ARG takes precedence (for lvconvert) */
tools: Unify stripesize parameter validation. Move it all into get_stripe_params(). Some code paths missed --stripesize checks. E.g. lvcreate --type raid4 -i1
2016-07-30 04:05:50 +03:00
/* FIXME Cope with relative +/- changes for lvconvert. */
toollib: improve stripes args reading Rewrite validation of stripes and stripe_size args into more readable sequential code. Extend reading of stripes & stripes_size args so it better knows defaults for types like striped raid. TODO: this should really be a value obtained for segtype structure and all the weird conditions and modification of stripes and stripe_size around lvm2 code should be dropped.
2017-11-27 12:26:35 +03:00
if (arg_is_set(cmd, stripes_long_ARG)) {
*stripes = arg_uint_value(cmd, stripes_long_ARG, 0);
*stripes_supplied = 1;
} else if (arg_is_set(cmd, stripes_ARG)) {
*stripes = arg_uint_value(cmd, stripes_ARG, 0);
*stripes_supplied = 1;
} else {
/*
* FIXME add segtype parameter for min_stripes and remove logic for this
* from all other places
*/
if (segtype_is_any_raid6(segtype))
*stripes = 3;
else if (segtype_is_striped_raid(segtype))
*stripes = 2;
else
*stripes = 1;
*stripes_supplied = 0;
}
Add --stripes to lvconvert too.
2010-04-13 05:54:32 +04:00
toollib: improve stripes args reading Rewrite validation of stripes and stripe_size args into more readable sequential code. Extend reading of stripes & stripes_size args so it better knows defaults for types like striped raid. TODO: this should really be a value obtained for segtype structure and all the weird conditions and modification of stripes and stripe_size around lvm2 code should be dropped.
2017-11-27 12:26:35 +03:00
if ((*stripe_size = arg_uint_value(cmd, stripesize_ARG, 0))) {
Using enum types for enums alloc_policy_t, dm_string_mangling_t, percent_range_t, sign_t
2012-02-28 18:24:57 +04:00
if (arg_sign_value(cmd, stripesize_ARG, SIGN_NONE) == SIGN_MINUS) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("Negative stripesize is invalid.");
Add --stripes to lvconvert too.
2010-04-13 05:54:32 +04:00
return 0;
}
}
toollib: improve stripes args reading Rewrite validation of stripes and stripe_size args into more readable sequential code. Extend reading of stripes & stripes_size args so it better knows defaults for types like striped raid. TODO: this should really be a value obtained for segtype structure and all the weird conditions and modification of stripes and stripe_size around lvm2 code should be dropped.
2017-11-27 12:26:35 +03:00
*stripe_size_supplied = arg_is_set(cmd, stripesize_ARG);
Add --stripes to lvconvert too.
2010-04-13 05:54:32 +04:00
tools: Unify stripesize parameter validation. Move it all into get_stripe_params(). Some code paths missed --stripesize checks. E.g. lvcreate --type raid4 -i1
2016-07-30 04:05:50 +03:00
return _validate_stripe_params(cmd, segtype, stripes, stripe_size);
Add --stripes to lvconvert too.
2010-04-13 05:54:32 +04:00
}
lvcreate: cachemode writeback and cachepolicy cleaner is invalid Return an error if lvconvert is used to create a cache pool with that combination.
2017-05-05 17:59:12 +03:00
static int _validate_cachepool_params(const char *policy_name, cache_mode_t cache_mode)
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
{
lvcreate: cachemode writeback and cachepolicy cleaner is invalid Return an error if lvconvert is used to create a cache pool with that combination.
2017-05-05 17:59:12 +03:00
/*
* FIXME: it might be nice if cmd def rules could check option values,
* then a rule could do this.
*/
if ((cache_mode == CACHE_MODE_WRITEBACK) && policy_name && !strcmp(policy_name, "cleaner")) {
log_error("Cache mode \"writeback\" is not compatible with cache policy \"cleaner\".");
return 0;
}
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
return 1;
}
toollib: get_cache_params Enhance get_cache_params() to read common cache args.
2015-07-23 16:35:12 +03:00
int get_cache_params(struct cmd_context *cmd,
cache: get and set cache params
2017-03-09 18:20:44 +03:00
uint32_t *chunk_size,
cache: enable usage of --cachemetadataformat lvcreate and lvconvert may select cache metadata format when caching LV. By default lvm2 picks best available format.
2017-02-26 22:18:37 +03:00
cache_metadata_format_t *cache_metadata_format,
lvchange: allow change of cache mode Add support for active cache LV. Handle --cachemode args validation during command line processing. Rework some lvm2 internal to use lvm2 defined CACHE_MODE enums indepently on libdm defines and use enum around the code instead of passing and comparing strings.
2016-04-25 14:39:30 +03:00
cache_mode_t *cache_mode,
toollib: get_cache_params Enhance get_cache_params() to read common cache args.
2015-07-23 16:35:12 +03:00
const char **name,
struct dm_config_tree **settings)
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
{
const char *str;
struct arg_value_group_list *group;
struct dm_config_tree *result = NULL, *prev = NULL, *current = NULL;
cleanup: drop unused vars
2014-11-20 19:49:32 +03:00
struct dm_config_node *cn;
toollib: Split --cachesettings from --cachepolicy.
2014-11-20 13:30:19 +03:00
int ok = 0;
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
cache: extend usability of cache_set_params Fix missing reset of '*settings' pointer when no args were given. Handle cache_chunk settings like all other settings, so it is properly updated only with non-zero settings and the existing cache-pool chunk_size is not being reconfigured.
2017-02-27 16:53:45 +03:00
if (arg_is_set(cmd, chunksize_ARG)) {
*chunk_size = arg_uint_value(cmd, chunksize_ARG, 0);
toollib: get_cache_params Enhance get_cache_params() to read common cache args.
2015-07-23 16:35:12 +03:00
cache: extend usability of cache_set_params Fix missing reset of '*settings' pointer when no args were given. Handle cache_chunk settings like all other settings, so it is properly updated only with non-zero settings and the existing cache-pool chunk_size is not being reconfigured.
2017-02-27 16:53:45 +03:00
if (!validate_cache_chunk_size(cmd, *chunk_size))
return_0;
toollib: get_cache_params Enhance get_cache_params() to read common cache args.
2015-07-23 16:35:12 +03:00
cache: extend usability of cache_set_params Fix missing reset of '*settings' pointer when no args were given. Handle cache_chunk settings like all other settings, so it is properly updated only with non-zero settings and the existing cache-pool chunk_size is not being reconfigured.
2017-02-27 16:53:45 +03:00
log_very_verbose("Setting pool chunk size to %s.",
display_size(cmd, *chunk_size));
}
cache: enable usage of --cachemetadataformat lvcreate and lvconvert may select cache metadata format when caching LV. By default lvm2 picks best available format.
2017-02-26 22:18:37 +03:00
*cache_metadata_format = (cache_metadata_format_t)
arg_uint_value(cmd, cachemetadataformat_ARG, CACHE_METADATA_FORMAT_UNSELECTED);
cache: extend usability of cache_set_params Fix missing reset of '*settings' pointer when no args were given. Handle cache_chunk settings like all other settings, so it is properly updated only with non-zero settings and the existing cache-pool chunk_size is not being reconfigured.
2017-02-27 16:53:45 +03:00
*cache_mode = (cache_mode_t) arg_uint_value(cmd, cachemode_ARG, CACHE_MODE_UNSELECTED);
*name = arg_str_value(cmd, cachepolicy_ARG, NULL);
cache: handle policy_name separately Keep policy name separate from policy settings and avoid to mangling and demangling this string from same config tree. Ensure policy_name is always defined.
2015-07-15 12:06:40 +03:00
lvcreate: cachemode writeback and cachepolicy cleaner is invalid Return an error if lvconvert is used to create a cache pool with that combination.
2017-05-05 17:59:12 +03:00
if (!_validate_cachepool_params(*name, *cache_mode))
goto_out;
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
dm_list_iterate_items(group, &cmd->arg_value_groups) {
toollib: Split --cachesettings from --cachepolicy.
2014-11-20 13:30:19 +03:00
if (!grouped_arg_is_set(group->arg_values, cachesettings_ARG))
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
continue;
cache: handle policy_name separately Keep policy name separate from policy settings and avoid to mangling and demangling this string from same config tree. Ensure policy_name is always defined.
2015-07-15 12:06:40 +03:00
if (!(current = dm_config_create()))
toollib: Split --cachesettings from --cachepolicy.
2014-11-20 13:30:19 +03:00
goto_out;
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
if (prev)
current->cascade = prev;
prev = current;
if (!(str = grouped_arg_str_value(group->arg_values,
toollib: Split --cachesettings from --cachepolicy.
2014-11-20 13:30:19 +03:00
cachesettings_ARG,
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
NULL)))
toollib: Split --cachesettings from --cachepolicy.
2014-11-20 13:30:19 +03:00
goto_out;
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
config: parse config tree without dup node checking if it's metadata tree
2016-09-21 15:27:15 +03:00
if (!dm_config_parse_without_dup_node_check(current, str, str + strlen(str)))
toollib: Split --cachesettings from --cachepolicy.
2014-11-20 13:30:19 +03:00
goto_out;
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
}
cache: extend usability of cache_set_params Fix missing reset of '*settings' pointer when no args were given. Handle cache_chunk settings like all other settings, so it is properly updated only with non-zero settings and the existing cache-pool chunk_size is not being reconfigured.
2017-02-27 16:53:45 +03:00
if (current) {
if (!(result = dm_config_flatten(current)))
goto_out;
toollib: get_cache_params Enhance get_cache_params() to read common cache args.
2015-07-23 16:35:12 +03:00
cache: extend usability of cache_set_params Fix missing reset of '*settings' pointer when no args were given. Handle cache_chunk settings like all other settings, so it is properly updated only with non-zero settings and the existing cache-pool chunk_size is not being reconfigured.
2017-02-27 16:53:45 +03:00
if (result->root) {
if (!(cn = dm_config_create_node(result, "policy_settings")))
goto_out;
toollib: Split --cachesettings from --cachepolicy.
2014-11-20 13:30:19 +03:00
cache: extend usability of cache_set_params Fix missing reset of '*settings' pointer when no args were given. Handle cache_chunk settings like all other settings, so it is properly updated only with non-zero settings and the existing cache-pool chunk_size is not being reconfigured.
2017-02-27 16:53:45 +03:00
cn->child = result->root;
result->root = cn;
}
cache: Fix a segfault when passing --cachepolicy without --cachesettings.
2015-02-24 13:36:30 +03:00
}
toollib: Split --cachesettings from --cachepolicy.
2014-11-20 13:30:19 +03:00
ok = 1;
out:
coverity: fix possible NULL dereference The call to dm_config_destroy can derefence result->mem while result is still NULL: struct dm_config_tree *get_cachepolicy_params(struct cmd_context *cmd) { ... int ok = 0; ... if (!(result = dm_config_flatten(current))) goto_out; ... ok = 1; out: if (!ok) { dm_config_destroy(result) ... } ... }
2014-11-26 13:46:13 +03:00
if (!ok && result) {
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
dm_config_destroy(result);
result = NULL;
}
while (prev) {
current = prev->cascade;
dm_config_destroy(prev);
prev = current;
}
cache: handle policy_name separately Keep policy name separate from policy settings and avoid to mangling and demangling this string from same config tree. Ensure policy_name is always defined.
2015-07-15 12:06:40 +03:00
*settings = result;
return ok;
toollib: Add --cachepolicy and implement get_cachepolicy_params.
2014-11-19 20:39:29 +03:00
}
vdo: support --vdosettings Allow to use --vdosettings with lvcreate,lvconvert,lvchange. Support settings currenly only configurable via lvm.conf. With lvchange we require inactivate LV for changes to be applied. Settings block_map_era_length has supported alias block_map_period.
2022-04-13 16:09:08 +03:00
/*
* Compare VDO option name, skip any '_' in name
* and also allow to use it without vdo_[use_] prefix
*/
static int _compare_vdo_option(const char *b1, const char *b2)
{
vdo: fix --vdosettings parser Parser was incorrectly parsing vdo_use_features - move the skip of 'use_' prefix into internal loop which handles skipping of '_'.
2022-08-15 14:14:03 +03:00
int use_skipped = 0;
vdo: support --vdosettings Allow to use --vdosettings with lvcreate,lvconvert,lvchange. Support settings currenly only configurable via lvm.conf. With lvchange we require inactivate LV for changes to be applied. Settings block_map_era_length has supported alias block_map_period.
2022-04-13 16:09:08 +03:00
if (strncasecmp(b1, "vdo", 3) == 0) // skip vdo prefix
b1 += 3;
while (*b1 && *b2) {
if (tolower(*b1) == tolower(*b2)) {
++b1;
++b2;
continue; // matching char
}
if (*b1 == '_')
++b1; // skip to next char
else if (*b2 == '_')
++b2; // skip to next char
vdo: fix --vdosettings parser Parser was incorrectly parsing vdo_use_features - move the skip of 'use_' prefix into internal loop which handles skipping of '_'.
2022-08-15 14:14:03 +03:00
else {
if (!use_skipped++ && (strncmp(b2, "use_", 4) == 0)) {
b2 += 4; // try again with skipped prefix 'use_'
continue;
}
vdo: support --vdosettings Allow to use --vdosettings with lvcreate,lvconvert,lvchange. Support settings currenly only configurable via lvm.conf. With lvchange we require inactivate LV for changes to be applied. Settings block_map_era_length has supported alias block_map_period.
2022-04-13 16:09:08 +03:00
break; // mismatch
vdo: fix --vdosettings parser Parser was incorrectly parsing vdo_use_features - move the skip of 'use_' prefix into internal loop which handles skipping of '_'.
2022-08-15 14:14:03 +03:00
}
vdo: support --vdosettings Allow to use --vdosettings with lvcreate,lvconvert,lvchange. Support settings currenly only configurable via lvm.conf. With lvchange we require inactivate LV for changes to be applied. Settings block_map_era_length has supported alias block_map_period.
2022-04-13 16:09:08 +03:00
}
return (*b1 || *b2) ? 0 : 1;
}
#define CHECK_AND_SET(var, onoff) \
option = #var;\
if (_compare_vdo_option(cn->key, option)) {\
if (is_lvchange || !cn->v || (cn->v->type != DM_CFG_INT))\
goto err;\
if (vtp->var != cn->v->v.i) {\
vtp->var = cn->v->v.i;\
u |= onoff;\
}\
continue;\
}
#define DO_OFFLINE(var) \
CHECK_AND_SET(var, VDO_CHANGE_OFFLINE)
#define DO_ONLINE(var) \
CHECK_AND_SET(var, VDO_CHANGE_ONLINE)
int get_vdo_settings(struct cmd_context *cmd,
struct dm_vdo_target_params *vtp,
int *updated)
{
const char *str, *option = NULL;
struct arg_value_group_list *group;
struct dm_config_tree *result = NULL, *prev = NULL, *current = NULL;
struct dm_config_node *cn;
int r = 0, u = 0, is_lvchange;
int use_compression = vtp->use_compression;
int use_deduplication = vtp->use_deduplication;
int checked_lvchange;
if (updated)
*updated = 0;
// Group all --vdosettings
dm_list_iterate_items(group, &cmd->arg_value_groups) {
if (!grouped_arg_is_set(group->arg_values, vdosettings_ARG))
continue;
if (!(current = dm_config_create()))
goto_out;
if (prev)
current->cascade = prev;
prev = current;
if (!(str = grouped_arg_str_value(group->arg_values,
vdosettings_ARG,
NULL)))
goto_out;
if (!dm_config_parse_without_dup_node_check(current, str, str + strlen(str)))
goto_out;
}
if (current) {
if (!(result = dm_config_flatten(current)))
goto_out;
checked_lvchange = !strcmp(cmd->name, "lvchange");
/* Use all acceptable VDO options */
for (cn = result->root; cn; cn = cn->sib) {
is_lvchange = 0;
DO_OFFLINE(ack_threads);
DO_OFFLINE(bio_rotation);
DO_OFFLINE(bio_threads);
DO_OFFLINE(block_map_cache_size_mb);
DO_OFFLINE(block_map_era_length);
DO_OFFLINE(block_map_period); // alias for block_map_era_length
DO_OFFLINE(cpu_threads);
DO_OFFLINE(hash_zone_threads);
DO_OFFLINE(logical_threads);
DO_OFFLINE(max_discard);
DO_OFFLINE(physical_threads);
// Support also these - even when we have regular opts for them
DO_ONLINE(use_compression);
DO_ONLINE(use_deduplication);
// Settings bellow cannot be changed with lvchange command
is_lvchange = checked_lvchange;
DO_OFFLINE(index_memory_size_mb);
DO_OFFLINE(minimum_io_size);
DO_OFFLINE(slab_size_mb);
DO_OFFLINE(use_metadata_hints);
DO_OFFLINE(use_sparse_index);
option = "write_policy";
if (_compare_vdo_option(cn->key, option)) {
if (is_lvchange || !cn->v || (cn->v->type != DM_CFG_STRING))
goto err;
if (!set_vdo_write_policy(&vtp->write_policy, cn->v->v.str))
goto_out;
u |= VDO_CHANGE_OFFLINE;
continue;
}
vdo: check_point_frequence is unused option This vdo parameter existed in the early stage of integration of vdo into lvm2, but later it's been removed from vdoformat tool - so actually if there would be any non-zero value it would cause error on lvcreate. Option was not stored on disk in lvm2 metadata. Remove this vdo parameter from lvm2 sources. (Although this vdo parameter will be still accepted on cmdline through --vdosettings option, but it will be ignored.)
2023-06-28 12:55:20 +03:00
if (_compare_vdo_option(cn->key, "check_point_frequency")) {
log_verbose("Ignoring deprecated --vdosettings option \"%s\" and its value.", cn->key);
continue; /* Accept & ignore deprecated option */
}
vdo: support --vdosettings Allow to use --vdosettings with lvcreate,lvconvert,lvchange. Support settings currenly only configurable via lvm.conf. With lvchange we require inactivate LV for changes to be applied. Settings block_map_era_length has supported alias block_map_period.
2022-04-13 16:09:08 +03:00
log_error("Unknown VDO setting \"%s\".", cn->key);
goto out;
}
}
if (arg_is_set(cmd, compression_ARG)) {
vtp->use_compression = arg_int_value(cmd, compression_ARG, 0);
if (vtp->use_compression != use_compression)
u |= VDO_CHANGE_ONLINE;
}
if (arg_is_set(cmd, deduplication_ARG)) {
vtp->use_deduplication = arg_int_value(cmd, deduplication_ARG, 0);
if (vtp->use_deduplication != use_deduplication)
u |= VDO_CHANGE_ONLINE;
}
vdo: suffle code for better error path handling For failing dm_ no need to report 2nd. error, but we missed to report error with 'updated==NULL'.
2022-07-09 22:33:57 +03:00
// validation of updated VDO option
if (!dm_vdo_validate_target_params(vtp, 0 /* vdo_size */))
goto_out;
vdo: support --vdosettings Allow to use --vdosettings with lvcreate,lvconvert,lvchange. Support settings currenly only configurable via lvm.conf. With lvchange we require inactivate LV for changes to be applied. Settings block_map_era_length has supported alias block_map_period.
2022-04-13 16:09:08 +03:00
vdo: suffle code for better error path handling For failing dm_ no need to report 2nd. error, but we missed to report error with 'updated==NULL'.
2022-07-09 22:33:57 +03:00
if (updated)
vdo: support --vdosettings Allow to use --vdosettings with lvcreate,lvconvert,lvchange. Support settings currenly only configurable via lvm.conf. With lvchange we require inactivate LV for changes to be applied. Settings block_map_era_length has supported alias block_map_period.
2022-04-13 16:09:08 +03:00
*updated = u;
vdo: suffle code for better error path handling For failing dm_ no need to report 2nd. error, but we missed to report error with 'updated==NULL'.
2022-07-09 22:33:57 +03:00
r = 1; // success
goto out;
err:
if (is_lvchange)
log_error("Cannot change VDO setting \"vdo_%s\" in existing VDO pool.",
option);
else
log_error("Invalid argument for VDO setting \"vdo_%s\".",
option);
vdo: support --vdosettings Allow to use --vdosettings with lvcreate,lvconvert,lvchange. Support settings currenly only configurable via lvm.conf. With lvchange we require inactivate LV for changes to be applied. Settings block_map_era_length has supported alias block_map_period.
2022-04-13 16:09:08 +03:00
out:
if (result)
dm_config_destroy(result);
while (prev) {
current = prev->cascade;
dm_config_destroy(prev);
prev = current;
}
return r;
}
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
static int _get_one_writecache_setting(struct cmd_context *cmd, struct writecache_settings *settings,
char *key, char *val, uint32_t *block_size_sectors)
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
{
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
/* special case: block_size is not a setting but is set with the --cachesettings option */
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "block_size", sizeof("block_size") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
uint32_t block_size = 0;
if (sscanf(val, "%u", &block_size) != 1)
goto_bad;
if (block_size == 512)
*block_size_sectors = 1;
else if (block_size == 4096)
*block_size_sectors = 8;
else
goto_bad;
return 1;
}
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "high_watermark", sizeof("high_watermark") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (sscanf(val, "%llu", (unsigned long long *)&settings->high_watermark) != 1)
goto_bad;
if (settings->high_watermark > 100)
goto_bad;
settings->high_watermark_set = 1;
return 1;
}
writecache: add settings cleaner and max_age available in dm-writecache 1.2
2020-03-31 22:14:50 +03:00
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "low_watermark", sizeof("low_watermark") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (sscanf(val, "%llu", (unsigned long long *)&settings->low_watermark) != 1)
goto_bad;
if (settings->low_watermark > 100)
goto_bad;
settings->low_watermark_set = 1;
return 1;
}
writecache: add settings cleaner and max_age available in dm-writecache 1.2
2020-03-31 22:14:50 +03:00
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "writeback_jobs", sizeof("writeback_jobs") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (sscanf(val, "%llu", (unsigned long long *)&settings->writeback_jobs) != 1)
goto_bad;
settings->writeback_jobs_set = 1;
return 1;
}
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "autocommit_blocks", sizeof("autocommit_blocks") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (sscanf(val, "%llu", (unsigned long long *)&settings->autocommit_blocks) != 1)
goto_bad;
settings->autocommit_blocks_set = 1;
return 1;
}
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "autocommit_time", sizeof("autocommit_time") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (sscanf(val, "%llu", (unsigned long long *)&settings->autocommit_time) != 1)
goto_bad;
settings->autocommit_time_set = 1;
return 1;
}
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "fua", sizeof("fua") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (settings->nofua_set) {
log_error("Setting fua and nofua cannot both be set.");
return 0;
}
if (sscanf(val, "%u", &settings->fua) != 1)
goto_bad;
settings->fua_set = 1;
return 1;
}
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "nofua", sizeof("nofua") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (settings->fua_set) {
log_error("Setting fua and nofua cannot both be set.");
return 0;
writecache: handle options from lvm.conf User can place default settings into lvm.conf i.e.: allocation { cache_settings { writecache { block_size = 4096 } } }
2022-01-20 17:36:14 +03:00
}
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (sscanf(val, "%u", &settings->nofua) != 1)
goto_bad;
settings->nofua_set = 1;
return 1;
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
}
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "cleaner", sizeof("cleaner") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (sscanf(val, "%u", &settings->cleaner) != 1)
goto_bad;
settings->cleaner_set = 1;
return 1;
}
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "max_age", sizeof("max_age") - 1)) {
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (sscanf(val, "%u", &settings->max_age) != 1)
goto_bad;
settings->max_age_set = 1;
return 1;
}
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "metadata_only", sizeof("metadata_only") - 1)) {
writecache: support settings metadata_only and pause_writeback Two new settings for tuning dm-writecache.
2022-12-09 01:42:04 +03:00
if (sscanf(val, "%u", &settings->metadata_only) != 1)
goto_bad;
settings->metadata_only_set = 1;
return 1;
}
cleanup: replace strlen with sizeof Use the string size from compile time.
2024-05-26 12:47:26 +03:00
if (!strncmp(key, "pause_writeback", sizeof("pause_writeback") - 1)) {
writecache: support settings metadata_only and pause_writeback Two new settings for tuning dm-writecache.
2022-12-09 01:42:04 +03:00
if (sscanf(val, "%u", &settings->pause_writeback) != 1)
goto_bad;
settings->pause_writeback_set = 1;
return 1;
}
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (settings->new_key) {
log_error("Setting %s is not recognized. Only one unrecognized setting is allowed.", key);
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
return 0;
}
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Unrecognized writecache setting \"%s\" may cause activation failure.", key);
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (yes_no_prompt("Use unrecognized writecache setting? [y/n]: ") == 'n') {
log_error("Aborting writecache conversion.");
return 0;
}
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Using unrecognized writecache setting: %s = %s.", key, val);
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
settings->new_key = dm_pool_strdup(cmd->mem, key);
settings->new_val = dm_pool_strdup(cmd->mem, val);
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
return 1;
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
bad:
log_error("Invalid setting: %s", key);
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
return 0;
}
int get_writecache_settings(struct cmd_context *cmd, struct writecache_settings *settings,
uint32_t *block_size_sectors)
{
writecache: look for settings in lvm.conf Restore the lvm.conf cache_settings for writecache added by c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Shorter method reduces and isolates the complexity of config trees.
2022-02-01 01:12:24 +03:00
const struct dm_config_node *cns, *cn1, *cn2;
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
struct arg_value_group_list *group;
const char *str;
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
char key[64];
char val[64];
int num;
gcc: correct signess comparation Compare int to int and unsigned to unsigned...
2023-07-13 13:32:44 +03:00
unsigned pos;
writecache: look for settings in lvm.conf Restore the lvm.conf cache_settings for writecache added by c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Shorter method reduces and isolates the complexity of config trees.
2022-02-01 01:12:24 +03:00
int rn;
int found = 0;
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
/*
* "grouped" means that multiple --cachesettings options can be used.
* Each option is also allowed to contain multiple key = val pairs.
*/
dm_list_iterate_items(group, &cmd->arg_value_groups) {
if (!grouped_arg_is_set(group->arg_values, cachesettings_ARG))
continue;
if (!(str = grouped_arg_str_value(group->arg_values, cachesettings_ARG, NULL)))
break;
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
pos = 0;
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
while (pos < strlen(str)) {
/* scan for "key1=val1 key2 = val2 key3= val3" */
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
memset(key, 0, sizeof(key));
memset(val, 0, sizeof(val));
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (sscanf(str + pos, " %63[^=]=%63s %n", key, val, &num) != 2) {
log_error("Invalid setting at: %s", str+pos);
return 0;
}
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
pos += num;
if (!_get_one_writecache_setting(cmd, settings, key, val, block_size_sectors))
return_0;
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
}
writecache: look for settings in lvm.conf Restore the lvm.conf cache_settings for writecache added by c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Shorter method reduces and isolates the complexity of config trees.
2022-02-01 01:12:24 +03:00
found = 1;
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
}
writecache: look for settings in lvm.conf Restore the lvm.conf cache_settings for writecache added by c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Shorter method reduces and isolates the complexity of config trees.
2022-02-01 01:12:24 +03:00
if (found)
goto out;
/*
* If there were no settings on the command line, look for settings in
* lvm.conf
*
* TODO: support profiles
*/
if (!(cns = find_config_tree_node(cmd, allocation_cache_settings_CFG_SECTION, NULL)))
goto out;
for (cn1 = cns->child; cn1; cn1 = cn1->sib) {
if (!cn1->child)
continue; /* Ignore section without settings */
if (cn1->v || strcmp(cn1->key, "writecache") != 0)
continue; /* Ignore non-matching settings */
cn2 = cn1->child;
for (; cn2; cn2 = cn2->sib) {
memset(val, 0, sizeof(val));
if (cn2->v->type == DM_CFG_INT)
rn = dm_snprintf(val, sizeof(val), FMTd64, cn2->v->v.i);
else if (cn2->v->type == DM_CFG_STRING)
rn = dm_snprintf(val, sizeof(val), "%s", cn2->v->v.str);
else
rn = -1;
if (rn < 0) {
log_error("Invalid lvm.conf writecache setting value for %s.", cn2->key);
return 0;
}
if (!_get_one_writecache_setting(cmd, settings, (char *)cn2->key, val, block_size_sectors))
return_0;
}
}
out:
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
if (settings->high_watermark_set && settings->low_watermark_set &&
(settings->high_watermark <= settings->low_watermark)) {
log_error("High watermark must be greater than low watermark.");
return 0;
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
}
Revert "writecache: handle options from lvm.conf" This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
2022-02-01 00:18:46 +03:00
return 1;
writecache: cachesettings in lvchange and lvs lvchange --cachesettings lvs -o+cache_settings
2020-02-26 23:47:29 +03:00
}
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
Add change_tag to toollib. Allow multiple pvchange command line options to be specified together.
2011-01-24 16:38:31 +03:00
/* FIXME move to lib */
static int _pv_change_tag(struct physical_volume *pv, const char *tag, int addtag)
{
if (addtag) {
if (!str_list_add(pv->fmt->cmd->mem, &pv->tags, tag)) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("Failed to add tag %s to physical volume %s.",
Add change_tag to toollib. Allow multiple pvchange command line options to be specified together.
2011-01-24 16:38:31 +03:00
tag, pv_dev_name(pv));
return 0;
}
Switch to return void List delete cannot fail, so there is no reason to test for error.
2012-02-08 16:52:58 +04:00
} else
str_list_del(&pv->tags, tag);
Add change_tag to toollib. Allow multiple pvchange command line options to be specified together.
2011-01-24 16:38:31 +03:00
return 1;
}
/* Set exactly one of VG, LV or PV */
int change_tag(struct cmd_context *cmd, struct volume_group *vg,
struct logical_volume *lv, struct physical_volume *pv, int arg)
{
const char *tag;
struct arg_value_group_list *current_group;
dm_list_iterate_items(current_group, &cmd->arg_value_groups) {
if (!grouped_arg_is_set(current_group->arg_values, arg))
continue;
if (!(tag = grouped_arg_str_value(current_group->arg_values, arg, NULL))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("Failed to get tag.");
Add change_tag to toollib. Allow multiple pvchange command line options to be specified together.
2011-01-24 16:38:31 +03:00
return 0;
}
if (vg && !vg_change_tag(vg, tag, arg == addtag_ARG))
return_0;
else if (lv && !lv_change_tag(lv, tag, arg == addtag_ARG))
return_0;
else if (pv && !_pv_change_tag(pv, tag, arg == addtag_ARG))
return_0;
}
return 1;
}
Fix possible overflow of size if %FREE or %VG is used. https://bugzilla.redhat.com/show_bug.cgi?id=737087
2011-09-15 19:26:40 +04:00
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
/*
* FIXME: replace process_each_label() with process_each_vg() which is
* based on performing vg_read(), which provides a correct representation
* of VGs/PVs, that is not provided by lvmcache_label_scan().
*/
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
int process_each_label(struct cmd_context *cmd, int argc, char **argv,
struct processing_handle *handle,
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
process_single_label_fn_t process_single_label)
{
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
log_report_t saved_log_report_state = log_get_report_state();
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
struct label *label;
struct dev_iter *iter;
struct device *dev;
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
struct lvmcache_info *info;
struct dm_list process_duplicates;
struct device_list *devl;
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
int ret_max = ECMD_PROCESSED;
toollib: drop init of ret Keep the ret uninitialized, so we get compiler warning, when tried to use this value instead of ret_max as function return value.
2013-11-23 01:27:32 +04:00
int ret;
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
int opt = 0;
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
dm_list_init(&process_duplicates);
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_LABEL);
exit with error when --devicesfile name doesn't exist
2022-07-06 01:08:00 +03:00
if (!lvmcache_label_scan(cmd)) {
ret_max = ECMD_FAILED;
goto_out;
}
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
if (argc) {
for (; opt < argc; opt++) {
toolib: move sigint_caught Move the check for catched signal to the loop front. Currently not much usable - but we can improve it later.
2021-02-27 21:22:11 +03:00
if (sigint_caught()) {
log_error("Interrupted.");
ret_max = ECMD_FAILED;
goto out;
}
devices: initial use of existing option Use dev_cache_get_existing() in a few common, high level locations where it's obvious that only existing dev-cache entries are wanted. This can be expanded and used in more locations (or dev_cache_get can stop creating new entries.)
2022-02-25 01:10:37 +03:00
if (!(dev = dev_cache_get_existing(cmd, argv[opt], cmd->filter))) {
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
log_error("Failed to find device "
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
"\"%s\".", argv[opt]);
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
ret_max = ECMD_FAILED;
continue;
}
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
if (!(label = lvmcache_get_dev_label(dev))) {
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
if (!lvmcache_dev_is_unused_duplicate(dev)) {
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
log_error("No physical volume label read from %s.", argv[opt]);
ret_max = ECMD_FAILED;
} else {
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
if (!(devl = malloc(sizeof(*devl))))
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
return_0;
devl->dev = dev;
dm_list_add(&process_duplicates, &devl->list);
}
continue;
}
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
log_set_report_object_name_and_id(dev_name(dev), NULL);
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
ret = process_single_label(cmd, label, handle);
report_log_ret_code(ret);
if (ret > ret_max)
ret_max = ret;
log_set_report_object_name_and_id(NULL, NULL);
}
dm_list_iterate_items(devl, &process_duplicates) {
toolib: move sigint_caught Move the check for catched signal to the loop front. Currently not much usable - but we can improve it later.
2021-02-27 21:22:11 +03:00
if (sigint_caught()) {
log_error("Interrupted.");
ret_max = ECMD_FAILED;
goto out;
}
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
/*
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
* remove the existing dev for this pvid from lvmcache
* so that the duplicate dev can replace it.
*/
if ((info = lvmcache_info_from_pvid(devl->dev->pvid, NULL, 0)))
lvmcache_del(info);
/*
* add info to lvmcache from the duplicate dev.
*/
fix segfault handling duplicate PVs cmd arg was missing when switching to use an alternative duplicate dev.
2021-10-14 22:02:59 +03:00
label_scan_dev(cmd, devl->dev);
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
/*
* the info/label should now be found because
* the label_read should have added it.
*/
if (!(label = lvmcache_get_dev_label(devl->dev)))
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
continue;
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
toollib: fix wrong dev reference in process_each_label
2018-04-30 17:08:40 +03:00
log_set_report_object_name_and_id(dev_name(devl->dev), NULL);
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
ret = process_single_label(cmd, label, handle);
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
report_log_ret_code(ret);
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
if (ret > ret_max)
ret_max = ret;
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
log_set_report_object_name_and_id(NULL, NULL);
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
}
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
goto out;
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
}
remove unused full filter it's the same as cmd->filter
2018-12-04 23:06:46 +03:00
if (!(iter = dev_iter_create(cmd->filter, 1))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("dev_iter creation failed.");
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
ret_max = ECMD_FAILED;
goto out;
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
}
toolib: move sigint_caught Move the check for catched signal to the loop front. Currently not much usable - but we can improve it later.
2021-02-27 21:22:11 +03:00
while ((dev = dev_iter_get(cmd, iter))) {
if (sigint_caught()) {
log_error("Interrupted.");
ret_max = ECMD_FAILED;
break;
}
process_each_label: use lvmcache In the same way as the other process_each functions. In the common case all the info that's needed can be used from lvmcache after a label scan. But this means that unchosen devs for duplicate PVs need to be handled explicitly.
2018-02-09 20:24:40 +03:00
if (!(label = lvmcache_get_dev_label(dev)))
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
continue;
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
log_set_report_object_name_and_id(dev_name(label->dev), NULL);
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
ret = process_single_label(cmd, label, handle);
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
report_log_ret_code(ret);
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
if (ret > ret_max)
ret_max = ret;
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
log_set_report_object_name_and_id(NULL, NULL);
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
}
dev_iter_destroy(iter);
log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code
2016-06-20 14:46:35 +03:00
out:
log_restore_report_state(saved_log_report_state);
toollib: Implement process_each_label.
2013-07-29 20:51:27 +04:00
return ret_max;
}
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
/*
* Parse persistent major minor parameters.
*
* --persistent is unspecified => state is deduced
* from presence of options --minor or --major.
*
* -Mn => --minor or --major not allowed.
*
* -My => --minor is required (and also --major on <=2.4)
*/
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
int get_and_validate_major_minor(const struct cmd_context *cmd,
const struct format_type *fmt,
int32_t *major, int32_t *minor)
{
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
if (arg_count(cmd, minor_ARG) > 1) {
log_error("Option --minor may not be repeated.");
return 0;
}
if (arg_count(cmd, major_ARG) > 1) {
log_error("Option -j|--major may not be repeated.");
return 0;
}
/* Check with default 'y' */
if (!arg_int_value(cmd, persistent_ARG, 1)) { /* -Mn */
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
if (arg_is_set(cmd, minor_ARG) || arg_is_set(cmd, major_ARG)) {
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
log_error("Options --major and --minor are incompatible with -Mn.");
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
return 0;
}
*major = *minor = -1;
return 1;
}
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
/* -1 cannot be entered as an argument for --major, --minor */
*major = arg_int_value(cmd, major_ARG, -1);
*minor = arg_int_value(cmd, minor_ARG, -1);
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
if (arg_is_set(cmd, persistent_ARG)) { /* -My */
if (*minor == -1) {
log_error("Please specify minor number with --minor when using -My.");
return 0;
}
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
}
if (!strncmp(cmd->kernel_vsn, "2.4.", 4)) {
/* Major is required for 2.4 */
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
if (arg_is_set(cmd, persistent_ARG) && *major < 0) {
log_error("Please specify major number with --major when using -My.");
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
return 0;
}
} else {
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
if (*major != -1) {
log_warn("WARNING: Ignoring supplied major number %d - "
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
"kernel assigns major numbers dynamically. "
"Using major number %d instead.",
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
*major, cmd->dev_types->device_mapper_major);
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
}
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
/* Stay with dynamic major:minor if minor is not specified. */
gcc: correct signess comparation Compare int to int and unsigned to unsigned...
2023-07-13 13:32:44 +03:00
*major = (*minor == -1) ? -1 : (int)cmd->dev_types->device_mapper_major;
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
}
toollib: persistent major minor Deduce -M from presence of --minor, --major option if not specified on command line.
2014-10-23 16:26:16 +04:00
if ((*minor != -1) && !validate_major_minor(cmd, fmt, *major, *minor))
cleanup: rename func Update name of function read_and_validate_major_minor and put it into the right header file toollib.h. (In release update for f09f85d027d8833)
2014-09-27 20:53:08 +04:00
return_0;
return 1;
}
toollib: introduce validate_lvname_param Function for parsing and validating of lvname parameter.
2014-09-28 14:57:39 +04:00
/*
* Validate lvname parameter
*
* If it contains vgname, it is extracted from lvname.
* If there is passed vgname, it is compared whether its the same name.
*/
int validate_lvname_param(struct cmd_context *cmd, const char **vg_name,
const char **lv_name)
{
const char *vgname;
const char *lvname;
if (!lv_name || !*lv_name)
return 1; /* NULL lvname is ok */
/* If contains VG name, extract it. */
if (strchr(*lv_name, (int) '/')) {
if (!(vgname = _extract_vgname(cmd, *lv_name, &lvname)))
return_0;
if (!*vg_name)
*vg_name = vgname;
else if (strcmp(vgname, *vg_name)) {
log_error("Please use a single volume group name "
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
"(\"%s\" or \"%s\").", vgname, *vg_name);
toollib: introduce validate_lvname_param Function for parsing and validating of lvname parameter.
2014-09-28 14:57:39 +04:00
return 0;
}
*lv_name = lvname;
}
toollib: validate also name In validate_lvname_param() call also validate_name().
2014-09-30 23:45:10 +04:00
if (!validate_name(*lv_name)) {
log_error("Logical volume name \"%s\" is invalid.",
*lv_name);
return 0;
}
toollib: introduce validate_lvname_param Function for parsing and validating of lvname parameter.
2014-09-28 14:57:39 +04:00
return 1;
}
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
toollib: validate_restricted_lvname_param Lets make a separate new function to validate names that has to follow up restriction rules.
2014-10-08 13:14:33 +04:00
/*
* Validate lvname parameter
* This name must follow restriction rules on prefixes and suffixes.
*
* If it contains vgname, it is extracted from lvname.
* If there is passed vgname, it is compared whether its the same name.
*/
int validate_restricted_lvname_param(struct cmd_context *cmd, const char **vg_name,
const char **lv_name)
{
if (!validate_lvname_param(cmd, vg_name, lv_name))
return_0;
if (lv_name && *lv_name && !apply_lvname_restrictions(*lv_name))
return_0;
cleanup: type cleanup Fix return code 1. Since we always check for !() - this fix has no other effect.
2016-06-24 01:35:03 +03:00
return 1;
toollib: validate_restricted_lvname_param Lets make a separate new function to validate names that has to follow up restriction rules.
2014-10-08 13:14:33 +04:00
}
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
/*
* Extract list of VG names and list of tags from command line arguments.
*/
static int _get_arg_vgnames(struct cmd_context *cmd,
int argc, char **argv,
vgextend: pass single vgname as process_each_vg arg Pass the single vgname as a new process_each_vg arg instead of setting a cmd flag to tell process_each_vg to take only the first vgname arg from argv. Other commands with different argv formats will be able to use it this way.
2015-12-01 02:00:26 +03:00
const char *one_vgname,
toollib: add vg name list arg to process_each_vg
2016-04-29 00:18:20 +03:00
struct dm_list *use_vgnames,
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
struct dm_list *arg_vgnames,
struct dm_list *arg_tags)
{
int opt = 0;
int ret_max = ECMD_PROCESSED;
const char *vg_name;
vgextend: pass single vgname as process_each_vg arg Pass the single vgname as a new process_each_vg arg instead of setting a cmd flag to tell process_each_vg to take only the first vgname arg from argv. Other commands with different argv formats will be able to use it this way.
2015-12-01 02:00:26 +03:00
if (one_vgname) {
if (!str_list_add(cmd->mem, arg_vgnames,
dm_pool_strdup(cmd->mem, one_vgname))) {
log_error("strlist allocation failed.");
return ECMD_FAILED;
}
return ret_max;
}
toollib: add vg name list arg to process_each_vg
2016-04-29 00:18:20 +03:00
if (use_vgnames && !dm_list_empty(use_vgnames)) {
dm_list_splice(arg_vgnames, use_vgnames);
return ret_max;
}
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
for (; opt < argc; opt++) {
vg_name = argv[opt];
vgextend: Use process_each_vg. Tags and --select are not yet supported because new code is needed to ensure exactly one VG matches before the VG starts to be processed.
2015-02-13 17:58:51 +03:00
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
if (*vg_name == '@') {
if (!validate_tag(vg_name + 1)) {
log_error("Skipping invalid tag: %s", vg_name);
if (ret_max < EINVALID_CMD_LINE)
ret_max = EINVALID_CMD_LINE;
continue;
}
vgextend: Use process_each_vg. Tags and --select are not yet supported because new code is needed to ensure exactly one VG matches before the VG starts to be processed.
2015-02-13 17:58:51 +03:00
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
if (!str_list_add(cmd->mem, arg_tags,
dm_pool_strdup(cmd->mem, vg_name + 1))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("strlist allocation failed.");
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
return ECMD_FAILED;
}
vgextend: Use process_each_vg. Tags and --select are not yet supported because new code is needed to ensure exactly one VG matches before the VG starts to be processed.
2015-02-13 17:58:51 +03:00
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
continue;
}
vg_name = skip_dev_dir(cmd, vg_name, NULL);
if (strchr(vg_name, '/')) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("Invalid volume group name %s.", vg_name);
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
if (ret_max < EINVALID_CMD_LINE)
ret_max = EINVALID_CMD_LINE;
continue;
}
vgextend: Use process_each_vg. Tags and --select are not yet supported because new code is needed to ensure exactly one VG matches before the VG starts to be processed.
2015-02-13 17:58:51 +03:00
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
if (!str_list_add(cmd->mem, arg_vgnames,
dm_pool_strdup(cmd->mem, vg_name))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("strlist allocation failed.");
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
return ECMD_FAILED;
}
}
return ret_max;
}
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
struct processing_handle *init_processing_handle(struct cmd_context *cmd, struct processing_handle *parent_handle)
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions The init_processing_handle, init_selection_handle and destroy_processing_handle are helper functions that allocate and initialize the handles used when processing items in process_each_* and related functions.
2014-11-28 16:46:18 +03:00
{
struct processing_handle *handle;
if (!(handle = dm_pool_zalloc(cmd->mem, sizeof(struct processing_handle)))) {
log_error("_init_processing_handle: failed to allocate memory for processing handle");
return NULL;
}
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
handle->parent = parent_handle;
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions The init_processing_handle, init_selection_handle and destroy_processing_handle are helper functions that allocate and initialize the handles used when processing items in process_each_* and related functions.
2014-11-28 16:46:18 +03:00
/*
* For any reporting tool, the internal_report_for_select is reset to 0
* automatically because the internal reporting/selection is simply not
* needed - the reporting/selection is already a part of the code path
* used there.
*
* *The internal report for select is only needed for non-reporting tools!*
*/
handle->internal_report_for_select = arg_is_set(cmd, select_ARG);
cmd: add '-H|--history' switch and wire it up in cmd_context and processing_handle This patch adds "include_historical_lvs" field to struct cmd_context to make it possible for the command to switch between original funcionality where no historical LVs are processed and functionality where historical LVs are taken into account (and reported or processed further). The switch between these modes is done using the '-H|--history' switch on command line. The include_historical_lvs state is then passed to process_each_* fns using the "include_historical_lvs" field within struct processing_handle.
2016-03-01 17:22:48 +03:00
handle->include_historical_lvs = cmd->include_historical_lvs;
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions The init_processing_handle, init_selection_handle and destroy_processing_handle are helper functions that allocate and initialize the handles used when processing items in process_each_* and related functions.
2014-11-28 16:46:18 +03:00
refactor: move report grouping and log reporting handles from processing_handle to cmd_context With patches that will follow, this will make it possible to widen log report coverage when commands are executed from lvm shell so the amount of messages that may end up in stderr/stdout instead of log report are minimized.
2016-08-03 16:37:14 +03:00
if (!parent_handle && !cmd->cmd_report.report_group) {
if (!report_format_init(cmd)) {
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
dm_pool_free(cmd->mem, handle);
return NULL;
}
log: log warnings and errors via report if set; add log_set_report* fns This patch adds structures and functions to reroute error and warning logs to log report, if it's set. There are 5 new functions: - log_set_report Set log report where logging will be rerouted. - log_set_report_context Set context globally so any report_cmdlog call will use it. - log_set_report_object_type Set object type globally so any report_cmdlog call will use it. - log_set_report_object_name_and_id Set object ID and name globally so any report_cmdlog call will use it. - log_set_report_object_group_and_group_id Set object group ID and name globally so any report_cmdlog call will use it. These functions will be called during LVM command processing so any logs which are rerouted to log report contain proper information about current processing state.
2016-05-03 12:46:52 +03:00
} else
refactor: move report grouping and log reporting handles from processing_handle to cmd_context With patches that will follow, this will make it possible to widen log report coverage when commands are executed from lvm shell so the amount of messages that may end up in stderr/stdout instead of log report are minimized.
2016-08-03 16:37:14 +03:00
cmd->cmd_report.saved_log_report_state = log_get_report_state();
toollib: add report_group and log_rh to processing_handle and initialize cmd processing log report Wire up report group creation with log report in struct processing_handle and call report_format_init during processing handle initialization (init_processing_handle fn) and destroy it while destroing processing handle (destroy_processing_handle fn). This way, all the LVM command processing using processing handle has access to log report via which the current command log can be reported as items are processed.
2016-05-23 11:16:29 +03:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_context(LOG_REPORT_CONTEXT_PROCESSING);
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions The init_processing_handle, init_selection_handle and destroy_processing_handle are helper functions that allocate and initialize the handles used when processing items in process_each_* and related functions.
2014-11-28 16:46:18 +03:00
return handle;
}
select: initialize selection handle for process_each_* fns with initial report type This is a followup patch for previous patchset that enables selection in process_each_* fns to fix an issue where field prefixes are not automatically used for fields in selection criteria. Use initial report type that matches the intention of each process_each_* functions: - _process_pvs_in_vg - PVS - process_each_vg - VGS - process_each_lv and process_each_lv_in_vg - LVS This is not normally needed for the selection handle init, BUT we would miss the field prefix matching, e.g. lvchange -ay -S 'name=lvol0' The "name" above would not work if we didn't initialize reporting with the LVS type at its start. If we pass proper init type, reporting code can deduce the prefix automatically ("lv_name" in this case). This report type is then changed further based on what selection criteria we have. When doing pure selection, not report output, the final report type is purely based on combination of this initial report type and report types of the fields used in selection criteria.
2015-02-10 15:46:37 +03:00
int init_selection_handle(struct cmd_context *cmd, struct processing_handle *handle,
cov: replace enum report_type_t with unsigned Another enum used as bitfield mask.
2024-05-27 16:10:58 +03:00
unsigned initial_report_type)
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions The init_processing_handle, init_selection_handle and destroy_processing_handle are helper functions that allocate and initialize the handles used when processing items in process_each_* and related functions.
2014-11-28 16:46:18 +03:00
{
struct selection_handle *sh;
report: recognize selection (-S|--select) for each subreport; make -S|--select groupable
2016-05-26 16:20:27 +03:00
const char *selection;
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions The init_processing_handle, init_selection_handle and destroy_processing_handle are helper functions that allocate and initialize the handles used when processing items in process_each_* and related functions.
2014-11-28 16:46:18 +03:00
if (!(sh = dm_pool_zalloc(cmd->mem, sizeof(struct selection_handle)))) {
log_error("_init_selection_handle: failed to allocate memory for selection handle");
return 0;
}
reporter: simplify --configreport handling for -S|--select and fix an issue reported by coverity Simplify code around _do_get_report_selection - remove "expected_idxs[]" argument which is superfluous and add "allow_single" switch instead to allow for recognition of "--configreport <report_name> -S" as well as single "-S" if needed. Null pointer dereferences (FORWARD_NULL) /safe/guest2/covscan/LVM2.2.02.158/tools/reporter.c: 961 in _do_report_get_selection() Null pointer dereferences (FORWARD_NULL) Dereferencing null pointer "single_args".
2016-06-27 11:14:17 +03:00
if (!report_get_single_selection(cmd, initial_report_type, &selection))
report: recognize selection (-S|--select) for each subreport; make -S|--select groupable
2016-05-26 16:20:27 +03:00
return_0;
select: initialize selection handle for process_each_* fns with initial report type This is a followup patch for previous patchset that enables selection in process_each_* fns to fix an issue where field prefixes are not automatically used for fields in selection criteria. Use initial report type that matches the intention of each process_each_* functions: - _process_pvs_in_vg - PVS - process_each_vg - VGS - process_each_lv and process_each_lv_in_vg - LVS This is not normally needed for the selection handle init, BUT we would miss the field prefix matching, e.g. lvchange -ay -S 'name=lvol0' The "name" above would not work if we didn't initialize reporting with the LVS type at its start. If we pass proper init type, reporting code can deduce the prefix automatically ("lv_name" in this case). This report type is then changed further based on what selection criteria we have. When doing pure selection, not report output, the final report type is purely based on combination of this initial report type and report types of the fields used in selection criteria.
2015-02-10 15:46:37 +03:00
sh->report_type = initial_report_type;
report: recognize selection (-S|--select) for each subreport; make -S|--select groupable
2016-05-26 16:20:27 +03:00
if (!(sh->selection_rh = report_init_for_selection(cmd, &sh->report_type, selection))) {
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions The init_processing_handle, init_selection_handle and destroy_processing_handle are helper functions that allocate and initialize the handles used when processing items in process_each_* and related functions.
2014-11-28 16:46:18 +03:00
dm_pool_free(cmd->mem, sh);
return_0;
}
handle->selection_handle = sh;
return 1;
}
cleanup: remove deallocate_handle_root arg from destroy_procesing_handle fnw
2015-02-13 12:42:21 +03:00
void destroy_processing_handle(struct cmd_context *cmd, struct processing_handle *handle)
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions The init_processing_handle, init_selection_handle and destroy_processing_handle are helper functions that allocate and initialize the handles used when processing items in process_each_* and related functions.
2014-11-28 16:46:18 +03:00
{
if (handle) {
if (handle->selection_handle && handle->selection_handle->selection_rh)
dm_report_free(handle->selection_handle->selection_rh);
log: log warnings and errors via report if set; add log_set_report* fns This patch adds structures and functions to reroute error and warning logs to log report, if it's set. There are 5 new functions: - log_set_report Set log report where logging will be rerouted. - log_set_report_context Set context globally so any report_cmdlog call will use it. - log_set_report_object_type Set object type globally so any report_cmdlog call will use it. - log_set_report_object_name_and_id Set object ID and name globally so any report_cmdlog call will use it. - log_set_report_object_group_and_group_id Set object group ID and name globally so any report_cmdlog call will use it. These functions will be called during LVM command processing so any logs which are rerouted to log report contain proper information about current processing state.
2016-05-03 12:46:52 +03:00
refactor: move report grouping and log reporting handles from processing_handle to cmd_context With patches that will follow, this will make it possible to widen log report coverage when commands are executed from lvm shell so the amount of messages that may end up in stderr/stdout instead of log report are minimized.
2016-08-03 16:37:14 +03:00
log_restore_report_state(cmd->cmd_report.saved_log_report_state);
log: log warnings and errors via report if set; add log_set_report* fns This patch adds structures and functions to reroute error and warning logs to log report, if it's set. There are 5 new functions: - log_set_report Set log report where logging will be rerouted. - log_set_report_context Set context globally so any report_cmdlog call will use it. - log_set_report_object_type Set object type globally so any report_cmdlog call will use it. - log_set_report_object_name_and_id Set object ID and name globally so any report_cmdlog call will use it. - log_set_report_object_group_and_group_id Set object group ID and name globally so any report_cmdlog call will use it. These functions will be called during LVM command processing so any logs which are rerouted to log report contain proper information about current processing state.
2016-05-03 12:46:52 +03:00
toollib: fix segfault if using -S|--select with log/report_command_log=1 setting When we are using -S|--select for non-reporting tools while using command log reporting (log/report_command_log=1 setting), we need to create an internal processing handle to handle the selection itself. In this case, the internal processing handle to execute the selection (to process the -S|--select) has a parent handle (that is processing the actual non-reporting command). When this parent handle exists, we can't destroy the command log report in destroy_processing_handle as there's still the parent processing to finish. The parent processing may still generate logs which need to be reported in the command log report. If the command log report was destroyed prematurely together with destroying the internal processing handle for -S|--select, then any subsequent log request from processing the actual command (and hence an attermpt to access the command log report) ended up with a segfault. See also: https://bugzilla.redhat.com/show_bug.cgi?id=2175220
2023-03-07 16:45:06 +03:00
/*
* Do not destroy current cmd->report_group and cmd->log_rh
* (the log report) yet if we're running interactively
* (== running in lvm shell) or if there's a parent handle
* (== we're executing nested processing, like it is when
* doing selection for parent's process_each_* processing).
*
* In both cases, there's still possible further processing
* to do outside the processing covered by the handle we are
* destroying here and for which we may still need to access
* the log report to cover the rest of the processing.
*
*/
if (!cmd->is_interactive && !handle->parent) {
lvm: shell: extend log report to cover whole lvm shell's main loop When lvm commands are executed in lvm shell, we cover the whole lvm command execution within this shell now. That means, all messages logged and status caught during each command execution is now recorded in the log report, including overall command's return code.
2016-08-04 14:42:57 +03:00
if (!dm_report_group_destroy(cmd->cmd_report.report_group))
stack;
cmd->cmd_report.report_group = NULL;
if (cmd->cmd_report.log_rh) {
dm_report_free(cmd->cmd_report.log_rh);
cmd->cmd_report.log_rh = NULL;
}
tools: add 'lvm lastlog' command for interactive query and display of last command's log If we're running in lvm shell, we can keep last command's log report for further query with possible different selection criteria for easy log lookup.
2016-05-20 16:30:58 +03:00
}
pvmove: fix possible memory pool corruption This is a hotfix for a bug introduced in 6d7dc87cb356162f912b13c8a0cd198037c0226b. The bug description: First we allocate memory for processing handle (at an address 1) then we allocate some memory on the same pool for later use in pvmove_poll function inside the process_each_pv function (at an address 2). After we jump out of process_each_pv we called destroy_processing_handle. As a result of destroying the handle memory pool could deallocate all memory at address 1 or higher. The pvmove_poll function tried to copy a memory allocated at address 2 that could be returned to the system. If it was so it led to segfault. We need to rethink proper fix but in the same time cmd->mem pool is recreated per each lvm command so this should not cause problems even when we run multiple commands in lvm shell. A valgrind snapshot of the corruption: Invalid read of size 1 at 0x4C29F92: strlen (mc_replace_strmem.c:403) by 0x5495F2E: dm_pool_strdup (pool.c:51) by 0x1592A7: _create_id (pvmove.c:774) by 0x159409: pvmove_poll (pvmove.c:796) by 0x1599E3: pvmove (pvmove.c:931) by 0x15105B: lvm_run_command (lvmcmdline.c:1655) by 0x1523C3: lvm2_main (lvmcmdline.c:2121) by 0x1754F3: main (lvm.c:22) Address 0xf15df8a is 138 bytes inside a block of size 8,192 free'd at 0x4C28430: free (vg_replace_malloc.c:446) by 0x5494E73: dm_free_wrapper (dbg_malloc.c:357) by 0x5495DE2: _free_chunk (pool-fast.c:318) by 0x549561C: dm_pool_free (pool-fast.c:151) by 0x164451: destroy_processing_handle (toollib.c:1837) by 0x1598C1: pvmove (pvmove.c:903) by 0x15105B: lvm_run_command (lvmcmdline.c:1655) by 0x1523C3: lvm2_main (lvmcmdline.c:2121) by 0x1754F3: main (lvm.c:22)
2016-02-12 13:34:26 +03:00
/*
* TODO: think about better alternatives:
* handle mempool, dm_alloc for handle memory...
*/
memset(handle, 0, sizeof(*handle));
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions The init_processing_handle, init_selection_handle and destroy_processing_handle are helper functions that allocate and initialize the handles used when processing items in process_each_* and related functions.
2014-11-28 16:46:18 +03:00
}
}
toollib: pass struct processing_handle to _select_match_* functions The "struct processing_handle" contains handles to drive the selection/matching so pass it to the _select_match_* functions which are entry points to the selection mechanism used in process_each_* and related functions. This is revised and edited version of former Dave Teigland's patch which provided starting point for all the select support in process_each_* fns.
2014-11-28 16:34:56 +03:00
int select_match_vg(struct cmd_context *cmd, struct processing_handle *handle,
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
struct volume_group *vg)
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
{
toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}
2016-05-31 10:08:59 +03:00
int r;
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
if (!handle->internal_report_for_select)
toollib: pass struct processing_handle to _select_match_* functions The "struct processing_handle" contains handles to drive the selection/matching so pass it to the _select_match_* functions which are entry points to the selection mechanism used in process_each_* and related functions. This is revised and edited version of former Dave Teigland's patch which provided starting point for all the select support in process_each_* fns.
2014-11-28 16:34:56 +03:00
return 1;
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
handle->selection_handle->orig_report_type = VGS;
toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}
2016-05-31 10:08:59 +03:00
if (!(r = report_for_selection(cmd, handle, NULL, vg, NULL)))
toollib: select: issue an error message for failed VG/LV/PV selection
2015-02-11 11:36:09 +03:00
log_error("Selection failed for VG %s.", vg->name);
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
handle->selection_handle->orig_report_type = 0;
report: add report_for_selection and use it in select_match_{pv,vg,lv} The report_for_selection does the actual "reporting for selection only". The selection status will be saved in struct selection_handle's "selected" variable.
2014-12-01 16:19:30 +03:00
toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}
2016-05-31 10:08:59 +03:00
return r;
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
}
toollib: pass struct processing_handle to _select_match_* functions The "struct processing_handle" contains handles to drive the selection/matching so pass it to the _select_match_* functions which are entry points to the selection mechanism used in process_each_* and related functions. This is revised and edited version of former Dave Teigland's patch which provided starting point for all the select support in process_each_* fns.
2014-11-28 16:34:56 +03:00
int select_match_lv(struct cmd_context *cmd, struct processing_handle *handle,
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
struct volume_group *vg, struct logical_volume *lv)
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
{
toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}
2016-05-31 10:08:59 +03:00
int r;
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
if (!handle->internal_report_for_select)
toollib: pass struct processing_handle to _select_match_* functions The "struct processing_handle" contains handles to drive the selection/matching so pass it to the _select_match_* functions which are entry points to the selection mechanism used in process_each_* and related functions. This is revised and edited version of former Dave Teigland's patch which provided starting point for all the select support in process_each_* fns.
2014-11-28 16:34:56 +03:00
return 1;
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
handle->selection_handle->orig_report_type = LVS;
toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}
2016-05-31 10:08:59 +03:00
if (!(r = report_for_selection(cmd, handle, NULL, vg, lv)))
toollib: select: issue an error message for failed VG/LV/PV selection
2015-02-11 11:36:09 +03:00
log_error("Selection failed for LV %s.", lv->name);
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
handle->selection_handle->orig_report_type = 0;
report: add report_for_selection and use it in select_match_{pv,vg,lv} The report_for_selection does the actual "reporting for selection only". The selection status will be saved in struct selection_handle's "selected" variable.
2014-12-01 16:19:30 +03:00
toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}
2016-05-31 10:08:59 +03:00
return r;
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
}
toollib: pass struct processing_handle to _select_match_* functions The "struct processing_handle" contains handles to drive the selection/matching so pass it to the _select_match_* functions which are entry points to the selection mechanism used in process_each_* and related functions. This is revised and edited version of former Dave Teigland's patch which provided starting point for all the select support in process_each_* fns.
2014-11-28 16:34:56 +03:00
int select_match_pv(struct cmd_context *cmd, struct processing_handle *handle,
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
struct volume_group *vg, struct physical_volume *pv)
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
{
toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}
2016-05-31 10:08:59 +03:00
int r;
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
if (!handle->internal_report_for_select)
toollib: pass struct processing_handle to _select_match_* functions The "struct processing_handle" contains handles to drive the selection/matching so pass it to the _select_match_* functions which are entry points to the selection mechanism used in process_each_* and related functions. This is revised and edited version of former Dave Teigland's patch which provided starting point for all the select support in process_each_* fns.
2014-11-28 16:34:56 +03:00
return 1;
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
handle->selection_handle->orig_report_type = PVS;
toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}
2016-05-31 10:08:59 +03:00
if (!(r = report_for_selection(cmd, handle, pv, vg, NULL)))
toollib: select: issue an error message for failed VG/LV/PV selection
2015-02-11 11:36:09 +03:00
log_error("Selection failed for PV %s.", dev_name(pv->dev));
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
handle->selection_handle->orig_report_type = 0;
report: add report_for_selection and use it in select_match_{pv,vg,lv} The report_for_selection does the actual "reporting for selection only". The selection status will be saved in struct selection_handle's "selected" variable.
2014-12-01 16:19:30 +03:00
toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}
2016-05-31 10:08:59 +03:00
return r;
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
}
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
static int _select_matches(struct processing_handle *handle)
{
if (!handle->internal_report_for_select)
return 1;
return handle->selection_handle->selected;
}
vgs, lvs: ignore error if VG is removed If a VG is removed between the time that 'vgs' or 'lvs' (with no args) creates the list of VGs and the time that it reads the VG to process it, then ignore the removed VG; don't report an error that it could not be found, since it wasn't named by the command.
2015-10-27 18:52:01 +03:00
static int _process_vgnameid_list(struct cmd_context *cmd, uint32_t read_flags,
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
struct dm_list *vgnameids_to_process,
struct dm_list *arg_vgnames,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct dm_list *arg_tags,
struct processing_handle *handle,
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
process_single_vg_fn_t process_single_vg)
{
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_report_t saved_log_report_state = log_get_report_state();
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
char uuid[64] __attribute__((aligned(8)));
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
struct volume_group *vg;
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
struct volume_group *error_vg = NULL;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
struct vgnameid_list *vgnl;
const char *vg_name;
const char *vg_uuid;
coverity: fix missing initialization ... Using uninitialized value "lockd_state" when calling "lockd_vg" (even though lockd_vg assigns 0 to the lockd_state, but it looks at previous state of lockd_state just before that so we need to have that properly initialized!) libdm/libdm-report.c:2934: uninit_use_in_call: Using uninitialized value "tm". Field "tm.tm_gmtoff" is uninitialized when calling "_get_final_time". daemons/lvmlockd/lvmlockctl.c:273: uninit_use_in_call: Using uninitialized element of array "r_name" when calling "format_info_r_action". (just added FIXME as this looks unfinished?)
2015-07-08 15:53:23 +03:00
uint32_t lockd_state = 0;
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
uint32_t error_flags = 0;
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
int whole_selected = 0;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
int ret_max = ECMD_PROCESSED;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
int ret;
int skip;
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
int notfound;
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
int is_lockd;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
int process_all = 0;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
int do_report_ret_code = 1;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_VG);
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
/*
* If no VG names or tags were supplied, then process all VGs.
*/
if (dm_list_empty(arg_vgnames) && dm_list_empty(arg_tags))
process_all = 1;
vgextend: Use process_each_vg. Tags and --select are not yet supported because new code is needed to ensure exactly one VG matches before the VG starts to be processed.
2015-02-13 17:58:51 +03:00
/*
vgextend: pass single vgname as process_each_vg arg Pass the single vgname as a new process_each_vg arg instead of setting a cmd flag to tell process_each_vg to take only the first vgname arg from argv. Other commands with different argv formats will be able to use it this way.
2015-12-01 02:00:26 +03:00
* FIXME If one_vgname, only proceed if exactly one VG matches tags or selection.
vgextend: Use process_each_vg. Tags and --select are not yet supported because new code is needed to ensure exactly one VG matches before the VG starts to be processed.
2015-02-13 17:58:51 +03:00
*/
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
dm_list_iterate_items(vgnl, vgnameids_to_process) {
vg_name = vgnl->vg_name;
vg_uuid = vgnl->vgid;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
skip = 0;
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
notfound = 0;
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
is_lockd = lvmcache_vg_is_lockd_type(cmd, vg_name, vg_uuid);
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
uuid[0] = '\0';
log: use separate 'orphan' report object type for orphan VGs
2016-06-14 14:21:53 +03:00
if (is_orphan_vg(vg_name)) {
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_ORPHAN);
log_set_report_object_name_and_id(vg_name + sizeof(VG_ORPHANS), uuid);
} else {
if (vg_uuid && !id_write_format((const struct id*)vg_uuid, uuid, sizeof(uuid)))
stack;
log_set_report_object_name_and_id(vg_name, uuid);
}
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
if (sigint_caught()) {
ret_max = ECMD_FAILED;
goto_out;
}
log_very_verbose("Processing VG %s %s", vg_name, uuid);
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
do_lockd:
if (is_lockd && !lockd_vg(cmd, vg_name, NULL, 0, &lockd_state)) {
debug: missing trace
2018-06-13 16:56:58 +03:00
stack;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
ret_max = ECMD_FAILED;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret_max);
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
continue;
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
vg = vg_read(cmd, vg_name, vg_uuid, read_flags, lockd_state, &error_flags, &error_vg);
if (_ignore_vg(cmd, error_flags, error_vg, vg_name, arg_vgnames, read_flags, &skip, &notfound)) {
Add lvmlockd
2015-03-05 23:00:44 +03:00
stack;
ret_max = ECMD_FAILED;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret_max);
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
if (error_vg)
unlock_and_release_vg(cmd, error_vg, vg_name);
Add lvmlockd
2015-03-05 23:00:44 +03:00
goto endvg;
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
}
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
if (error_vg)
unlock_and_release_vg(cmd, error_vg, vg_name);
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
if (skip || notfound)
Add lvmlockd
2015-03-05 23:00:44 +03:00
goto endvg;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
if (!is_lockd && vg_is_shared(vg)) {
/* The lock_type changed since label_scan, won't really occur in practice. */
log_debug("Repeat lock and read for local to shared vg");
unlock_and_release_vg(cmd, vg, vg_name);
is_lockd = 1;
goto do_lockd;
}
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
/* Process this VG? */
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
if ((process_all ||
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
(!dm_list_empty(arg_vgnames) && str_list_match_item(arg_vgnames, vg_name)) ||
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
(!dm_list_empty(arg_tags) && str_list_match_list(arg_tags, &vg->tags, NULL))) &&
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
select_match_vg(cmd, handle, vg) && _select_matches(handle)) {
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
log_very_verbose("Running command for VG %s %s", vg_name, vg_uuid ? uuid : "");
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
ret = process_single_vg(cmd, vg_name, vg, handle);
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
_update_selection_result(handle, &whole_selected);
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (ret != ECMD_PROCESSED)
stack;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret);
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (ret > ret_max)
ret_max = ret;
}
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
unlock_vg(cmd, vg, vg_name);
Add lvmlockd
2015-03-05 23:00:44 +03:00
endvg:
release_vg(vg);
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
if (is_lockd && !lockd_vg(cmd, vg_name, "un", 0, &lockd_state))
lockd: check for failing unlock Avoid ignoring unlocking error.
2015-08-18 12:46:42 +03:00
stack;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
}
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
/* the VG is selected if at least one LV is selected */
_set_final_selection_result(handle, whole_selected);
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
do_report_ret_code = 0;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
out:
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
if (do_report_ret_code)
report_log_ret_code(ret_max);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_restore_report_state(saved_log_report_state);
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
return ret_max;
}
process_each: resolve duplicate VG names If two different VGs with the same name exist on the system, a command that just specifies that ambiguous name will fail with a new error: $ vgs -o name,uuid ... foo qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf foo vfhKCP-mpc7-KLLL-Uh08-4xPG-zLNR-4cnxJX $ lvs foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ vgremove foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ lvs -S vg_uuid=qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf lv1 foo ... This is implemented for process_each_vg/lv, and works with or without lvmetad. It does not work for commands that do not use process_each. This change includes one exception to the behavior shown above. If one of the VGs is foreign, and the other is not, then the command assumes that the intended VG is the local one and uses it.
2015-11-30 21:11:01 +03:00
/*
* Check if a command line VG name is ambiguous, i.e. there are multiple VGs on
* the system that have the given name. If *one* VG with the given name is
* local and the rest are foreign, then use the local VG (removing foreign VGs
* with the same name from the vgnameids_on_system list). If multiple VGs with
* the given name are local, we don't know which VG is intended, so remove the
* ambiguous name from the list of args.
*/
static int _resolve_duplicate_vgnames(struct cmd_context *cmd,
struct dm_list *arg_vgnames,
struct dm_list *vgnameids_on_system)
{
struct dm_str_list *sl, *sl2;
struct vgnameid_list *vgnl, *vgnl2;
char uuid[64] __attribute__((aligned(8)));
int found;
int ret = ECMD_PROCESSED;
dm_list_iterate_items_safe(sl, sl2, arg_vgnames) {
found = 0;
dm_list_iterate_items(vgnl, vgnameids_on_system) {
if (strcmp(sl->str, vgnl->vg_name))
continue;
found++;
}
if (found < 2)
continue;
/*
* More than one VG match the given name.
* If only one is local, use that one.
*/
found = 0;
dm_list_iterate_items_safe(vgnl, vgnl2, vgnameids_on_system) {
if (strcmp(sl->str, vgnl->vg_name))
continue;
/*
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
* label scan has already populated lvmcache vginfo with
* this information.
process_each: resolve duplicate VG names If two different VGs with the same name exist on the system, a command that just specifies that ambiguous name will fail with a new error: $ vgs -o name,uuid ... foo qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf foo vfhKCP-mpc7-KLLL-Uh08-4xPG-zLNR-4cnxJX $ lvs foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ vgremove foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ lvs -S vg_uuid=qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf lv1 foo ... This is implemented for process_each_vg/lv, and works with or without lvmetad. It does not work for commands that do not use process_each. This change includes one exception to the behavior shown above. If one of the VGs is foreign, and the other is not, then the command assumes that the intended VG is the local one and uses it.
2015-11-30 21:11:01 +03:00
*/
if (lvmcache_vg_is_foreign(cmd, vgnl->vg_name, vgnl->vgid)) {
coverity: missing check for id_write_format return value
2016-05-31 10:56:10 +03:00
if (!id_write_format((const struct id*)vgnl->vgid, uuid, sizeof(uuid)))
stack;
process_each: resolve duplicate VG names If two different VGs with the same name exist on the system, a command that just specifies that ambiguous name will fail with a new error: $ vgs -o name,uuid ... foo qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf foo vfhKCP-mpc7-KLLL-Uh08-4xPG-zLNR-4cnxJX $ lvs foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ vgremove foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ lvs -S vg_uuid=qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf lv1 foo ... This is implemented for process_each_vg/lv, and works with or without lvmetad. It does not work for commands that do not use process_each. This change includes one exception to the behavior shown above. If one of the VGs is foreign, and the other is not, then the command assumes that the intended VG is the local one and uses it.
2015-11-30 21:11:01 +03:00
dm_list_del(&vgnl->list);
} else {
found++;
}
}
if (found < 2)
continue;
/*
* More than one VG with this name is local so the intended VG
* is unknown.
*/
log_error("Multiple VGs found with the same name: skipping %s", sl->str);
toollib: provide proper hint for referencing VG uuid in case of duplicate VG names vgrename does not support -S|--select, so do not provide a hint about using it. Instead, provide a hint about using VG uuid directly. ❯ vgs WARNING: VG name vg1 is used by VGs DXjcSK-gWfu-5gLh-9Kbg-sG49-dtRr-GqXzGL and MVMfyM-sjOa-M2xV-AT4Y-JddR-h4SP-UO5Ttk. Fix duplicate VG names with vgrename uuid, a device filter, or system IDs. VG #PV #LV #SN Attr VSize VFree vg1 1 0 0 wz--n- 124.00m 124.00m vg1 1 0 0 wz--n- 124.00m 124.00m (vgrename does not support -S|--select) ❯ vgrename vg1 vg2 WARNING: VG name vg1 is used by VGs DXjcSK-gWfu-5gLh-9Kbg-sG49-dtRr-GqXzGL and MVMfyM-sjOa-M2xV-AT4Y-JddR-h4SP-UO5Ttk. Fix duplicate VG names with vgrename uuid, a device filter, or system IDs. Multiple VGs found with the same name: skipping vg1 Use VG uuid in place of the VG name. (vgchange does support -S|--select) ❯ vgchange --addtag a vg1 WARNING: VG name vg1 is used by VGs DXjcSK-gWfu-5gLh-9Kbg-sG49-dtRr-GqXzGL and MVMfyM-sjOa-M2xV-AT4Y-JddR-h4SP-UO5Ttk. Fix duplicate VG names with vgrename uuid, a device filter, or system IDs. Multiple VGs found with the same name: skipping vg1 Use --select vg_uuid=<uuid> in place of the VG name.
2023-05-16 18:17:55 +03:00
if (arg_is_valid_for_command(cmd, select_ARG))
log_error("Use --select vg_uuid=<uuid> in place of the VG name.");
else
log_error("Use VG uuid in place of the VG name.");
process_each: resolve duplicate VG names If two different VGs with the same name exist on the system, a command that just specifies that ambiguous name will fail with a new error: $ vgs -o name,uuid ... foo qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf foo vfhKCP-mpc7-KLLL-Uh08-4xPG-zLNR-4cnxJX $ lvs foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ vgremove foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ lvs -S vg_uuid=qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf lv1 foo ... This is implemented for process_each_vg/lv, and works with or without lvmetad. It does not work for commands that do not use process_each. This change includes one exception to the behavior shown above. If one of the VGs is foreign, and the other is not, then the command assumes that the intended VG is the local one and uses it.
2015-11-30 21:11:01 +03:00
dm_list_del(&sl->list);
ret = ECMD_FAILED;
}
return ret;
}
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
/*
* For each arg_vgname, move the corresponding entry from
* vgnameids_on_system to vgnameids_to_process. If an
* item in arg_vgnames doesn't exist in vgnameids_on_system,
* then add a new entry for it to vgnameids_to_process.
*/
static void _choose_vgs_to_process(struct cmd_context *cmd,
struct dm_list *arg_vgnames,
struct dm_list *vgnameids_on_system,
struct dm_list *vgnameids_to_process)
{
toollib: allow VG UUID to be used in place of VG name If the VG arg from the command line does not match the name of any known VGs, then check if the arg looks like a UUID. If it's a valid UUID, then compare it to the UUID of known VGs. If it matches the UUID of a known VG, then process that VG.
2015-12-01 21:00:57 +03:00
char uuid[64] __attribute__((aligned(8)));
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
struct dm_str_list *sl, *sl2;
struct vgnameid_list *vgnl, *vgnl2;
toollib: allow VG UUID to be used in place of VG name If the VG arg from the command line does not match the name of any known VGs, then check if the arg looks like a UUID. If it's a valid UUID, then compare it to the UUID of known VGs. If it matches the UUID of a known VG, then process that VG.
2015-12-01 21:00:57 +03:00
struct id id;
toollib: only interpret vgname arg as uuid for vgrename In general, --select should be used to specify a VG by UUID, but vgrename already allows a uuid to be substituted for the name, so continue to allow it in that case.
2015-12-02 00:50:14 +03:00
int arg_is_uuid = 0;
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
int found;
dm_list_iterate_items_safe(sl, sl2, arg_vgnames) {
found = 0;
dm_list_iterate_items_safe(vgnl, vgnl2, vgnameids_on_system) {
if (strcmp(sl->str, vgnl->vg_name))
continue;
dm_list_del(&vgnl->list);
dm_list_add(vgnameids_to_process, &vgnl->list);
found = 1;
break;
}
toollib: allow VG UUID to be used in place of VG name If the VG arg from the command line does not match the name of any known VGs, then check if the arg looks like a UUID. If it's a valid UUID, then compare it to the UUID of known VGs. If it matches the UUID of a known VG, then process that VG.
2015-12-01 21:00:57 +03:00
/*
* If the VG name arg looks like a UUID, then check if it
toollib: only interpret vgname arg as uuid for vgrename In general, --select should be used to specify a VG by UUID, but vgrename already allows a uuid to be substituted for the name, so continue to allow it in that case.
2015-12-02 00:50:14 +03:00
* matches the UUID of a VG. (--select should generally
* be used to select a VG by uuid instead.)
toollib: allow VG UUID to be used in place of VG name If the VG arg from the command line does not match the name of any known VGs, then check if the arg looks like a UUID. If it's a valid UUID, then compare it to the UUID of known VGs. If it matches the UUID of a known VG, then process that VG.
2015-12-01 21:00:57 +03:00
*/
command struct: remove command name refs Change run time access to the command_name struct cmd->cname instead of indirectly through cmd->command->cname. This removes the two run time fields from struct command.
2017-01-14 00:08:51 +03:00
if (!found && (cmd->cname->flags & ALLOW_UUID_AS_NAME))
cleanup: use try_id_read_format Better then using log_suppress in this case.
2015-12-03 17:26:44 +03:00
arg_is_uuid = id_read_format_try(&id, sl->str);
toollib: allow VG UUID to be used in place of VG name If the VG arg from the command line does not match the name of any known VGs, then check if the arg looks like a UUID. If it's a valid UUID, then compare it to the UUID of known VGs. If it matches the UUID of a known VG, then process that VG.
2015-12-01 21:00:57 +03:00
if (!found && arg_is_uuid) {
dm_list_iterate_items_safe(vgnl, vgnl2, vgnameids_on_system) {
if (!(id_write_format((const struct id*)vgnl->vgid, uuid, sizeof(uuid))))
continue;
if (strcmp(sl->str, uuid))
continue;
log_print("Processing VG %s because of matching UUID %s",
vgnl->vg_name, uuid);
dm_list_del(&vgnl->list);
dm_list_add(vgnameids_to_process, &vgnl->list);
/* Make the arg_vgnames entry use the actual VG name. */
sl->str = dm_pool_strdup(cmd->mem, vgnl->vg_name);
found = 1;
break;
}
}
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
/*
* If the name arg was not found in the list of all VGs, then
* it probably doesn't exist, but we want the "VG not found"
* failure to be handled by the existing vg_read() code for
* that error. So, create an entry with just the VG name so
* that the processing loop will attempt to process it and use
* the vg_read() error path.
*/
if (!found) {
log_verbose("VG name on command line not found in list of VGs: %s", sl->str);
if (!(vgnl = dm_pool_alloc(cmd->mem, sizeof(*vgnl))))
continue;
vgnl->vgid = NULL;
if (!(vgnl->vg_name = dm_pool_strdup(cmd->mem, sl->str)))
continue;
dm_list_add(vgnameids_to_process, &vgnl->list);
}
}
}
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
/*
* Call process_single_vg() for each VG selected by the command line arguments.
toollib: add vg name list arg to process_each_vg
2016-04-29 00:18:20 +03:00
* If one_vgname is set, process only that VG and ignore argc/argv (which should be 0/NULL).
vgextend: pass single vgname as process_each_vg arg Pass the single vgname as a new process_each_vg arg instead of setting a cmd flag to tell process_each_vg to take only the first vgname arg from argv. Other commands with different argv formats will be able to use it this way.
2015-12-01 02:00:26 +03:00
* If one_vgname is not set, get VG names to process from argc/argv.
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
*/
toollib: add vg name list arg to process_each_vg
2016-04-29 00:18:20 +03:00
int process_each_vg(struct cmd_context *cmd,
int argc, char **argv,
const char *one_vgname,
struct dm_list *use_vgnames,
uint32_t read_flags,
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
int include_internal,
vgextend: pass single vgname as process_each_vg arg Pass the single vgname as a new process_each_vg arg instead of setting a cmd flag to tell process_each_vg to take only the first vgname arg from argv. Other commands with different argv formats will be able to use it this way.
2015-12-01 02:00:26 +03:00
struct processing_handle *handle,
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
process_single_vg_fn_t process_single_vg)
{
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_report_t saved_log_report_state = log_get_report_state();
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
int handle_supplied = handle != NULL;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
struct dm_list arg_tags; /* str_list */
struct dm_list arg_vgnames; /* str_list */
struct dm_list vgnameids_on_system; /* vgnameid_list */
struct dm_list vgnameids_to_process; /* vgnameid_list */
command struct: remove command name refs Change run time access to the command_name struct cmd->cname instead of indirectly through cmd->command->cname. This removes the two run time fields from struct command.
2017-01-14 00:08:51 +03:00
int enable_all_vgs = (cmd->cname->flags & ALL_VGS_IS_DEFAULT);
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
int process_all_vgs_on_system = 0;
int ret_max = ECMD_PROCESSED;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
int ret;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_VG);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
log_debug("Processing each VG");
Add lvmlockd
2015-03-05 23:00:44 +03:00
/* Disable error in vg_read so we can print it from ignore_vg. */
cmd->vg_read_print_access_error = 0;
system_id: remove unwanted foreign error for some commands Commands that can never use foreign VGs begin with cmd->error_foreign_vgs = 1. This tells the vg_read lib layer to print an error as soon as a foreign VG is read. The toollib process_each layer also prints an error if a foreign VG is read, but is more selective about it. It won't print an error if the command did not explicitly name the foreign VG. We want to silently ignore foreign VGs unless a command attempts to use one explicitly. So, foreign VG errors are printed from two different layers: vg_read (lower layer) and process_each (upper layer). Commands that use toollib process_each, only want errors from the process_each layer, not from both layers. So, process_each disables the lower layer vg_read error message by setting error_foreign_vgs = 0. Commands that do not use toollib process_each, want errors from the vg_read layer, otherwise they would get no error message. The original cmd->error_foreign_vgs setting enables this error. (Commands that are allowed to operate on foreign VGs always begin with cmd->error_foreign_vgs = 0, and all the commands in this group use toollib process_each with the selective error reporting.)
2015-02-27 01:06:32 +03:00
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
dm_list_init(&arg_tags);
dm_list_init(&arg_vgnames);
dm_list_init(&vgnameids_on_system);
dm_list_init(&vgnameids_to_process);
/*
* Find any VGs or tags explicitly provided on the command line.
*/
toollib: add vg name list arg to process_each_vg
2016-04-29 00:18:20 +03:00
if ((ret = _get_arg_vgnames(cmd, argc, argv, one_vgname, use_vgnames, &arg_vgnames, &arg_tags)) != ECMD_PROCESSED) {
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ret;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
goto_out;
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
}
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
/*
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
* Process all VGs on the system when:
* . tags are specified and all VGs need to be read to
* look for matching tags.
* . no VG names are specified and the command defaults
* to processing all VGs when none are specified.
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
*/
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
if ((dm_list_empty(&arg_vgnames) && enable_all_vgs) || !dm_list_empty(&arg_tags))
process_all_vgs_on_system = 1;
Add lvmlockd
2015-03-05 23:00:44 +03:00
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
/*
* Needed for a current listing of the global VG namespace.
*/
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 (process_all_vgs_on_system && !lock_global(cmd, "sh")) {
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ECMD_FAILED;
goto_out;
}
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
/*
scan: do scanning at the start of a command Move the location of scans to make it clearer and avoid unnecessary repeated scanning. There should be one scan at the start of a command which is then used through the rest of command processing. Previously, the initial label scan was called as a side effect from various utility functions. This would lead to it being called unnecessarily. It is an expensive operation, and should only be called when necessary. Also, this is a primary step in the function of the command, and as such it should be called prominently at the top level of command processing, not as a hidden side effect of a utility function. lvm knows exactly where and when the label scan needs to be done. Because of this, move the label scan calls from the internal functions to the top level of processing. Other specific instances of lvmcache_label_scan() are still called unnecessarily or unclearly by specific commands that do not use the common process_each functions. These will be improved in future commits. During the processing phase, rescanning labels for devices in a VG needs to be done after the VG lock is acquired in case things have changed since the initial label scan. This was being done by way of rescanning devices that had the INVALID flag set in lvmcache. This usually approximated the right set of devices, but it was not exact, and obfuscated the real requirement. Correct this by using a new function that rescans the devices in the VG: lvmcache_label_rescan_vg(). Apart from being inexact, the rescanning was extremely well hidden. _vg_read() would call ->create_instance(), _text_create_text_instance(), _create_vg_text_instance() which would call lvmcache_label_scan() which would call _scan_invalid() which repeats the label scan on devices flagged INVALID. lvmcache_label_rescan_vg() is now called prominently by _vg_read() directly.
2018-02-07 22:26:37 +03:00
* Scan all devices to populate lvmcache with initial
* list of PVs and VGs.
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
*/
exit with error when --devicesfile name doesn't exist
2022-07-06 01:08:00 +03:00
if (!(read_flags & PROCESS_SKIP_SCAN)) {
if (!lvmcache_label_scan(cmd)) {
ret_max = ECMD_FAILED;
goto_out;
}
}
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
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
/*
* A list of all VGs on the system is needed when:
* . processing all VGs on the system
* . A VG name is specified which may refer to one
* of multiple VGs on the system with that name.
*/
log: Improve various device-related messages - Use 'lvmcache' consistently instead of 'metadata cache' - Always use 5 characters for source line number - Remember to convert uuids into printable form - Use <no name> rather than (null) when VG has no name.
2017-11-13 17:43:32 +03:00
log_very_verbose("Obtaining the complete list of VGs to process");
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
lvmcache: remove wrapper around lvmcache_get_vgnameids This was left over from when there was an lvmetad version of the function.
2019-06-11 22:09:13 +03:00
if (!lvmcache_get_vgnameids(cmd, &vgnameids_on_system, NULL, include_internal)) {
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ECMD_FAILED;
goto_out;
Add lvmlockd
2015-03-05 23:00:44 +03:00
}
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
process_each: resolve duplicate VG names If two different VGs with the same name exist on the system, a command that just specifies that ambiguous name will fail with a new error: $ vgs -o name,uuid ... foo qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf foo vfhKCP-mpc7-KLLL-Uh08-4xPG-zLNR-4cnxJX $ lvs foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ vgremove foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ lvs -S vg_uuid=qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf lv1 foo ... This is implemented for process_each_vg/lv, and works with or without lvmetad. It does not work for commands that do not use process_each. This change includes one exception to the behavior shown above. If one of the VGs is foreign, and the other is not, then the command assumes that the intended VG is the local one and uses it.
2015-11-30 21:11:01 +03:00
if (!dm_list_empty(&arg_vgnames)) {
/* This may remove entries from arg_vgnames or vgnameids_on_system. */
ret = _resolve_duplicate_vgnames(cmd, &arg_vgnames, &vgnameids_on_system);
if (ret > ret_max)
ret_max = ret;
if (dm_list_empty(&arg_vgnames) && dm_list_empty(&arg_tags)) {
ret_max = ECMD_FAILED;
goto out;
}
}
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
if (dm_list_empty(&arg_vgnames) && dm_list_empty(&vgnameids_on_system)) {
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
/* FIXME Should be log_print, but suppressed for reporting cmds */
debug: switch to verbose When there is no real error from the function - avoid using log_error().
2014-11-14 18:11:43 +03:00
log_verbose("No volume groups found.");
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ECMD_PROCESSED;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
goto out;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
}
vgs, lvs: ignore error if VG is removed If a VG is removed between the time that 'vgs' or 'lvs' (with no args) creates the list of VGs and the time that it reads the VG to process it, then ignore the removed VG; don't report an error that it could not be found, since it wasn't named by the command.
2015-10-27 18:52:01 +03:00
if (dm_list_empty(&arg_vgnames))
read_flags |= READ_OK_NOTFOUND;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
/*
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
* When processing all VGs, vgnameids_on_system simply becomes
* vgnameids_to_process.
* When processing only specified VGs, then for each item in
* arg_vgnames, move the corresponding entry from
* vgnameids_on_system to vgnameids_to_process.
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
*/
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
if (process_all_vgs_on_system)
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
dm_list_splice(&vgnameids_to_process, &vgnameids_on_system);
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
else
_choose_vgs_to_process(cmd, &arg_vgnames, &vgnameids_on_system, &vgnameids_to_process);
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
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 && !(handle = init_processing_handle(cmd, NULL))) {
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ECMD_FAILED;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
goto_out;
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
}
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
if (handle->internal_report_for_select && !handle->selection_handle &&
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
!init_selection_handle(cmd, handle, VGS)) {
ret_max = ECMD_FAILED;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
goto_out;
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
}
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
vgs, lvs: ignore error if VG is removed If a VG is removed between the time that 'vgs' or 'lvs' (with no args) creates the list of VGs and the time that it reads the VG to process it, then ignore the removed VG; don't report an error that it could not be found, since it wasn't named by the command.
2015-10-27 18:52:01 +03:00
ret = _process_vgnameid_list(cmd, read_flags, &vgnameids_to_process,
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
&arg_vgnames, &arg_tags, handle, process_single_vg);
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
if (ret > ret_max)
ret_max = ret;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
out:
if (!handle_supplied)
cleanup: remove deallocate_handle_root arg from destroy_procesing_handle fnw
2015-02-13 12:42:21 +03:00
destroy_processing_handle(cmd, handle);
vgextend: Use process_each_vg. Tags and --select are not yet supported because new code is needed to ensure exactly one VG matches before the VG starts to be processed.
2015-02-13 17:58:51 +03:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_restore_report_state(saved_log_report_state);
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
return ret_max;
toollib: Rewrite process_each_vg. Split VG argument collection from processing. This allows the two different loops through VGs to be replaced by a single loop. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. [Committed by agk with cosmetic changes and tweaks.]
2014-10-03 23:47:19 +04:00
}
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
static struct dm_str_list *_str_list_match_item_with_prefix(const struct dm_list *sll, const char *prefix, const char *str)
{
struct dm_str_list *sl;
size_t prefix_len = strlen(prefix);
dm_list_iterate_items(sl, sll) {
if (!strncmp(prefix, sl->str, prefix_len) &&
!strcmp(sl->str + prefix_len, str))
return sl;
}
return NULL;
}
/*
* Dummy LV, segment type and segment to represent all historical LVs.
*/
static struct logical_volume _historical_lv = {
.name = "",
.major = -1,
.minor = -1,
.snapshot_segs = DM_LIST_HEAD_INIT(_historical_lv.snapshot_segs),
.segments = DM_LIST_HEAD_INIT(_historical_lv.segments),
.tags = DM_LIST_HEAD_INIT(_historical_lv.tags),
.segs_using_this_lv = DM_LIST_HEAD_INIT(_historical_lv.segs_using_this_lv),
.indirect_glvs = DM_LIST_HEAD_INIT(_historical_lv.indirect_glvs),
.hostname = "",
};
static struct segment_type _historical_segment_type = {
.name = "historical",
.flags = SEG_VIRTUAL | SEG_CANNOT_BE_ZEROED,
};
static struct lv_segment _historical_lv_segment = {
.lv = &_historical_lv,
.segtype = &_historical_segment_type,
.len = 0,
.tags = DM_LIST_HEAD_INIT(_historical_lv_segment.tags),
.origin_list = DM_LIST_HEAD_INIT(_historical_lv_segment.origin_list),
};
command: futher move to single struct Refactor code to not allocate memory for rule->opts, instead use uint16_t array of MAX_RULE_OPTS within cmd_rule. Also print more info if array would not be enough (>= 8).
2024-05-11 01:42:49 +03:00
int opt_in_list_is_set(struct cmd_context *cmd, const uint16_t *opts, int count,
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
int *match_count, int *unmatch_count)
{
int match = 0;
int unmatch = 0;
int i;
for (i = 0; i < count; i++) {
if (arg_is_set(cmd, opts[i]))
match++;
else
unmatch++;
}
if (match_count)
*match_count = match;
if (unmatch_count)
*unmatch_count = unmatch;
return match ? 1 : 0;
}
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
command: futher move to single struct Refactor code to not allocate memory for rule->opts, instead use uint16_t array of MAX_RULE_OPTS within cmd_rule. Also print more info if array would not be enough (>= 8).
2024-05-11 01:42:49 +03:00
void opt_array_to_str(struct cmd_context *cmd, const uint16_t *opts, int count,
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
char *buf, int len)
{
int pos = 0;
int ret;
int i;
for (i = 0; i < count; i++) {
ret = snprintf(buf + pos, len - pos, "%s ", arg_long_option_name(opts[i]));
if (ret >= len - pos)
break;
pos += ret;
}
buf[len - 1] = '\0';
}
tidy: Add missing underscores to statics.
2017-10-18 17:57:46 +03:00
static void _lvp_bits_to_str(uint64_t bits, char *buf, int len)
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
{
command: more static const declaration Use static const for declared arrays. Access to arrays through get_ functions().
2024-04-28 20:52:26 +03:00
const struct lv_prop *prop;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
int lvp_enum;
int pos = 0;
int ret;
for (lvp_enum = 0; lvp_enum < LVP_COUNT; lvp_enum++) {
if (!(prop = get_lv_prop(lvp_enum)))
continue;
if (lvp_bit_is_set(bits, lvp_enum)) {
ret = snprintf(buf + pos, len - pos, "%s ", prop->name);
if (ret >= len - pos)
break;
pos += ret;
}
}
buf[len - 1] = '\0';
}
tidy: Add missing underscores to statics.
2017-10-18 17:57:46 +03:00
static void _lvt_bits_to_str(uint64_t bits, char *buf, int len)
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
{
command: more static const declaration Use static const for declared arrays. Access to arrays through get_ functions().
2024-04-28 20:52:26 +03:00
const struct lv_type *type;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
int lvt_enum;
int pos = 0;
int ret;
for (lvt_enum = 0; lvt_enum < LVT_COUNT; lvt_enum++) {
if (!(type = get_lv_type(lvt_enum)))
continue;
if (lvt_bit_is_set(bits, lvt_enum)) {
ret = snprintf(buf + pos, len - pos, "%s ", type->name);
if (ret >= len - pos)
break;
pos += ret;
}
}
buf[len - 1] = '\0';
}
/*
* This is the lv_prop function pointer used for lv_is_foo() #defines.
* Alternatively, lv_is_foo() could all be turned into functions.
*/
static int _lv_is_prop(struct cmd_context *cmd, struct logical_volume *lv, int lvp_enum)
{
switch (lvp_enum) {
case is_locked_LVP:
return lv_is_locked(lv);
case is_partial_LVP:
return lv_is_partial(lv);
case is_virtual_LVP:
return lv_is_virtual(lv);
case is_merging_LVP:
return lv_is_merging(lv);
case is_merging_origin_LVP:
return lv_is_merging_origin(lv);
case is_converting_LVP:
return lv_is_converting(lv);
case is_external_origin_LVP:
return lv_is_external_origin(lv);
case is_virtual_origin_LVP:
return lv_is_virtual_origin(lv);
case is_not_synced_LVP:
return lv_is_not_synced(lv);
case is_pending_delete_LVP:
return lv_is_pending_delete(lv);
case is_error_when_full_LVP:
return lv_is_error_when_full(lv);
case is_pvmove_LVP:
return lv_is_pvmove(lv);
case is_removed_LVP:
return lv_is_removed(lv);
commands: add lv_is_writable
2023-08-09 14:43:45 +03:00
case is_writable_LVP:
return lv_is_writable(lv);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
case is_vg_writable_LVP:
return (lv->vg->status & LVM_WRITE) ? 1 : 0;
case is_thinpool_data_LVP:
return lv_is_thin_pool_data(lv);
case is_thinpool_metadata_LVP:
return lv_is_thin_pool_metadata(lv);
case is_cachepool_data_LVP:
return lv_is_cache_pool_data(lv);
case is_cachepool_metadata_LVP:
return lv_is_cache_pool_metadata(lv);
case is_mirror_image_LVP:
return lv_is_mirror_image(lv);
case is_mirror_log_LVP:
return lv_is_mirror_log(lv);
case is_raid_image_LVP:
return lv_is_raid_image(lv);
case is_raid_metadata_LVP:
return lv_is_raid_metadata(lv);
case is_origin_LVP: /* use lv_is_thick_origin */
return lv_is_origin(lv);
case is_thick_origin_LVP:
return lv_is_thick_origin(lv);
case is_thick_snapshot_LVP:
return lv_is_thick_snapshot(lv);
case is_thin_origin_LVP:
return lv_is_thin_origin(lv, NULL);
case is_thin_snapshot_LVP:
return lv_is_thin_snapshot(lv);
case is_cache_origin_LVP:
return lv_is_cache_origin(lv);
case is_merging_cow_LVP:
return lv_is_merging_cow(lv);
commands: support query for lv_is_cow
2023-07-04 14:31:56 +03:00
case is_cow_LVP:
return lv_is_cow(lv);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
case is_cow_covering_origin_LVP:
return lv_is_cow_covering_origin(lv);
case is_visible_LVP:
return lv_is_visible(lv);
commands: error and zero segtype handling Add function to work with error and zero LVs more easily.
2023-07-04 14:26:57 +03:00
case is_error_LVP:
return lv_is_error(lv);
case is_zero_LVP:
return lv_is_zero(lv);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
case is_historical_LVP:
return lv_is_historical(lv);
case is_raid_with_tracking_LVP:
return lv_is_raid_with_tracking(lv);
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
case is_raid_with_integrity_LVP:
return lv_raid_has_integrity(lv);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
default:
log_error(INTERNAL_ERROR "unknown lv property value lvp_enum %d", lvp_enum);
}
return 0;
}
/*
* Check if an LV matches a given LV type enum.
*/
static int _lv_is_type(struct cmd_context *cmd, struct logical_volume *lv, int lvt_enum)
{
struct lv_segment *seg = first_seg(lv);
switch (lvt_enum) {
case striped_LVT:
return seg_is_striped(seg) && !lv_is_cow(lv);
case linear_LVT:
return seg_is_linear(seg) && !lv_is_cow(lv);
case snapshot_LVT:
return lv_is_cow(lv);
case thin_LVT:
return lv_is_thin_volume(lv);
case thinpool_LVT:
return lv_is_thin_pool(lv);
case cache_LVT:
return lv_is_cache(lv);
case cachepool_LVT:
return lv_is_cache_pool(lv);
toollib: support new command rules queries Add: LV_vdo, LV_vdopool, LV_vdopooldata
2018-07-02 11:50:41 +03:00
case vdo_LVT:
return lv_is_vdo(lv);
case vdopool_LVT:
return lv_is_vdo_pool(lv);
case vdopooldata_LVT:
return lv_is_vdo_pool_data(lv);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
case mirror_LVT:
return lv_is_mirror(lv);
case raid_LVT:
return lv_is_raid(lv);
case raid0_LVT:
commands: recognize raid variations
2017-02-06 20:51:06 +03:00
return seg_is_any_raid0(seg);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
case raid1_LVT:
return seg_is_raid1(seg);
case raid4_LVT:
return seg_is_raid4(seg);
case raid5_LVT:
commands: recognize raid variations
2017-02-06 20:51:06 +03:00
return seg_is_any_raid5(seg);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
case raid6_LVT:
commands: recognize raid variations
2017-02-06 20:51:06 +03:00
return seg_is_any_raid6(seg);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
case raid10_LVT:
return seg_is_raid10(seg);
Add dm-writecache support dm-writecache is used like dm-cache with a standard LV as the cache. $ lvcreate -n main -L 128M -an foo /dev/loop0 $ lvcreate -n fast -L 32M -an foo /dev/pmem0 $ lvconvert --type writecache --cachepool fast foo/main $ lvs -a foo -o+devices LV VG Attr LSize Origin Devices [fast] foo -wi------- 32.00m /dev/pmem0(0) main foo Cwi------- 128.00m [main_wcorig] main_wcorig(0) [main_wcorig] foo -wi------- 128.00m /dev/loop0(0) $ lvchange -ay foo/main $ dmsetup table foo-main_wcorig: 0 262144 linear 7:0 2048 foo-main: 0 262144 writecache p 253:4 253:3 4096 0 foo-fast: 0 65536 linear 259:0 2048 $ lvchange -an foo/main $ lvconvert --splitcache foo/main $ lvs -a foo -o+devices LV VG Attr LSize Devices fast foo -wi------- 32.00m /dev/pmem0(0) main foo -wi------- 128.00m /dev/loop0(0)
2018-08-27 22:53:09 +03:00
case writecache_LVT:
return seg_is_writecache(seg);
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
case integrity_LVT:
return seg_is_integrity(seg);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
case error_LVT:
commands: error and zero segtype handling Add function to work with error and zero LVs more easily.
2023-07-04 14:26:57 +03:00
return seg_is_error(seg);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
case zero_LVT:
commands: error and zero segtype handling Add function to work with error and zero LVs more easily.
2023-07-04 14:26:57 +03:00
return seg_is_zero(seg);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
default:
log_error(INTERNAL_ERROR "unknown lv type value lvt_enum %d", lvt_enum);
}
return 0;
}
lvconvert: use command defs for thin/cache/pool creation Everything related to thin and cache.
2016-12-07 23:30:57 +03:00
int get_lvt_enum(struct logical_volume *lv)
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
{
struct lv_segment *seg = first_seg(lv);
/*
* The order these are checked is important, because a snapshot LV has
* a linear seg type.
*/
if (lv_is_cow(lv))
return snapshot_LVT;
if (seg_is_linear(seg))
return linear_LVT;
if (seg_is_striped(seg))
return striped_LVT;
if (lv_is_thin_volume(lv))
return thin_LVT;
if (lv_is_thin_pool(lv))
return thinpool_LVT;
if (lv_is_cache(lv))
return cache_LVT;
if (lv_is_cache_pool(lv))
return cachepool_LVT;
toollib: support new command rules queries Add: LV_vdo, LV_vdopool, LV_vdopooldata
2018-07-02 11:50:41 +03:00
if (lv_is_vdo(lv))
return vdo_LVT;
if (lv_is_vdo_pool(lv))
return vdopool_LVT;
if (lv_is_vdo_pool_data(lv))
return vdopooldata_LVT;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
if (lv_is_mirror(lv))
return mirror_LVT;
if (lv_is_raid(lv))
return raid_LVT;
commands: recognize raid variations
2017-02-06 20:51:06 +03:00
if (seg_is_any_raid0(seg))
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
return raid0_LVT;
if (seg_is_raid1(seg))
return raid1_LVT;
if (seg_is_raid4(seg))
return raid4_LVT;
commands: recognize raid variations
2017-02-06 20:51:06 +03:00
if (seg_is_any_raid5(seg))
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
return raid5_LVT;
commands: recognize raid variations
2017-02-06 20:51:06 +03:00
if (seg_is_any_raid6(seg))
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
return raid6_LVT;
if (seg_is_raid10(seg))
return raid10_LVT;
Add dm-writecache support dm-writecache is used like dm-cache with a standard LV as the cache. $ lvcreate -n main -L 128M -an foo /dev/loop0 $ lvcreate -n fast -L 32M -an foo /dev/pmem0 $ lvconvert --type writecache --cachepool fast foo/main $ lvs -a foo -o+devices LV VG Attr LSize Origin Devices [fast] foo -wi------- 32.00m /dev/pmem0(0) main foo Cwi------- 128.00m [main_wcorig] main_wcorig(0) [main_wcorig] foo -wi------- 128.00m /dev/loop0(0) $ lvchange -ay foo/main $ dmsetup table foo-main_wcorig: 0 262144 linear 7:0 2048 foo-main: 0 262144 writecache p 253:4 253:3 4096 0 foo-fast: 0 65536 linear 259:0 2048 $ lvchange -an foo/main $ lvconvert --splitcache foo/main $ lvs -a foo -o+devices LV VG Attr LSize Devices fast foo -wi------- 32.00m /dev/pmem0(0) main foo -wi------- 128.00m /dev/loop0(0)
2018-08-27 22:53:09 +03:00
if (seg_is_writecache(seg))
return writecache_LVT;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
if (seg_is_integrity(seg))
return integrity_LVT;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
commands: error and zero segtype handling Add function to work with error and zero LVs more easily.
2023-07-04 14:26:57 +03:00
if (seg_is_error(seg))
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
return error_LVT;
commands: error and zero segtype handling Add function to work with error and zero LVs more easily.
2023-07-04 14:26:57 +03:00
if (seg_is_zero(seg))
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
return zero_LVT;
return 0;
}
/*
* Call lv_is_<type> for each <type>_LVT bit set in lvt_bits.
* If lv matches one of the specified lv types, then return 1.
*/
static int _lv_types_match(struct cmd_context *cmd, struct logical_volume *lv, uint64_t lvt_bits,
uint64_t *match_bits, uint64_t *unmatch_bits)
{
command: more static const declaration Use static const for declared arrays. Access to arrays through get_ functions().
2024-04-28 20:52:26 +03:00
const struct lv_type *type;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
int lvt_enum;
int found_a_match = 0;
int match;
if (match_bits)
*match_bits = 0;
if (unmatch_bits)
*unmatch_bits = 0;
for (lvt_enum = 1; lvt_enum < LVT_COUNT; lvt_enum++) {
if (!lvt_bit_is_set(lvt_bits, lvt_enum))
continue;
if (!(type = get_lv_type(lvt_enum)))
continue;
/*
* All types are currently handled by _lv_is_type()
* because lv_is_type() are #defines and not exposed
* in tools.h
*/
lv_type: simplier macro usage Use more simple macros - as there is likely not going to happen any macro replacement - so use more effient structure layout.
2024-05-13 02:11:05 +03:00
match = _lv_is_type(cmd, lv, lvt_enum);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
if (match)
found_a_match = 1;
if (match_bits && match)
*match_bits |= lvt_enum_to_bit(lvt_enum);
if (unmatch_bits && !match)
*unmatch_bits |= lvt_enum_to_bit(lvt_enum);
}
return found_a_match;
}
/*
* Call lv_is_<prop> for each <prop>_LVP bit set in lvp_bits.
* If lv matches all of the specified lv properties, then return 1.
*/
static int _lv_props_match(struct cmd_context *cmd, struct logical_volume *lv, uint64_t lvp_bits,
uint64_t *match_bits, uint64_t *unmatch_bits)
{
command: more static const declaration Use static const for declared arrays. Access to arrays through get_ functions().
2024-04-28 20:52:26 +03:00
const struct lv_prop *prop;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
int lvp_enum;
int found_a_mismatch = 0;
int match;
if (match_bits)
*match_bits = 0;
if (unmatch_bits)
*unmatch_bits = 0;
for (lvp_enum = 1; lvp_enum < LVP_COUNT; lvp_enum++) {
if (!lvp_bit_is_set(lvp_bits, lvp_enum))
continue;
if (!(prop = get_lv_prop(lvp_enum)))
continue;
lv_prop: simplier macro usage Use more simple macros - as there is likely not going to happen any macro replacement - so use more effient structure layout.
2024-05-13 02:01:18 +03:00
match = _lv_is_prop(cmd, lv, lvp_enum);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
if (!match)
found_a_mismatch = 1;
if (match_bits && match)
*match_bits |= lvp_enum_to_bit(lvp_enum);
if (unmatch_bits && !match)
*unmatch_bits |= lvp_enum_to_bit(lvp_enum);
}
return !found_a_mismatch;
}
static int _check_lv_types(struct cmd_context *cmd, struct logical_volume *lv, int pos)
{
coverity: drop unneeded assigns
2017-06-27 12:38:56 +03:00
int ret;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
if (!pos)
return 1;
if (!cmd->command->required_pos_args[pos-1].def.lvt_bits)
return 1;
if (!val_bit_is_set(cmd->command->required_pos_args[pos-1].def.val_bits, lv_VAL)) {
commands: move command def parsing into lvm binary It was previously done at build time by the ccmd binary.
2017-02-10 20:36:11 +03:00
log_error(INTERNAL_ERROR "Command %d:%s arg position %d does not permit an LV (%llx)",
command: use command_id_to_enum Instead of storing command_id as string, direcly translate string to enum index and use 'command_enum()' to get string when needed for printing. This way we can easily detect error in the structure while parsing it - and we can later avoid separate 'translation' loop.
2024-05-12 17:00:48 +03:00
cmd->command->command_index, command_enum(cmd->command->command_enum),
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
pos, (unsigned long long)cmd->command->required_pos_args[pos-1].def.val_bits);
return 0;
}
ret = _lv_types_match(cmd, lv, cmd->command->required_pos_args[pos-1].def.lvt_bits, NULL, NULL);
if (!ret) {
lvconvert: use command defs for thin/cache/pool creation Everything related to thin and cache.
2016-12-07 23:30:57 +03:00
int lvt_enum = get_lvt_enum(lv);
command: more static const declaration Use static const for declared arrays. Access to arrays through get_ functions().
2024-04-28 20:52:26 +03:00
const struct lv_type *type = get_lv_type(lvt_enum);
Add dm-writecache support dm-writecache is used like dm-cache with a standard LV as the cache. $ lvcreate -n main -L 128M -an foo /dev/loop0 $ lvcreate -n fast -L 32M -an foo /dev/pmem0 $ lvconvert --type writecache --cachepool fast foo/main $ lvs -a foo -o+devices LV VG Attr LSize Origin Devices [fast] foo -wi------- 32.00m /dev/pmem0(0) main foo Cwi------- 128.00m [main_wcorig] main_wcorig(0) [main_wcorig] foo -wi------- 128.00m /dev/loop0(0) $ lvchange -ay foo/main $ dmsetup table foo-main_wcorig: 0 262144 linear 7:0 2048 foo-main: 0 262144 writecache p 253:4 253:3 4096 0 foo-fast: 0 65536 linear 259:0 2048 $ lvchange -an foo/main $ lvconvert --splitcache foo/main $ lvs -a foo -o+devices LV VG Attr LSize Devices fast foo -wi------- 32.00m /dev/pmem0(0) main foo -wi------- 128.00m /dev/loop0(0)
2018-08-27 22:53:09 +03:00
if (!type) {
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s does not accept LV type unknown (%d).",
Add dm-writecache support dm-writecache is used like dm-cache with a standard LV as the cache. $ lvcreate -n main -L 128M -an foo /dev/loop0 $ lvcreate -n fast -L 32M -an foo /dev/pmem0 $ lvconvert --type writecache --cachepool fast foo/main $ lvs -a foo -o+devices LV VG Attr LSize Origin Devices [fast] foo -wi------- 32.00m /dev/pmem0(0) main foo Cwi------- 128.00m [main_wcorig] main_wcorig(0) [main_wcorig] foo -wi------- 128.00m /dev/loop0(0) $ lvchange -ay foo/main $ dmsetup table foo-main_wcorig: 0 262144 linear 7:0 2048 foo-main: 0 262144 writecache p 253:4 253:3 4096 0 foo-fast: 0 65536 linear 259:0 2048 $ lvchange -an foo/main $ lvconvert --splitcache foo/main $ lvs -a foo -o+devices LV VG Attr LSize Devices fast foo -wi------- 32.00m /dev/pmem0(0) main foo -wi------- 128.00m /dev/loop0(0)
2018-08-27 22:53:09 +03:00
display_lvname(lv), lvt_enum);
} else {
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s does not accept LV type %s.",
Add dm-writecache support dm-writecache is used like dm-cache with a standard LV as the cache. $ lvcreate -n main -L 128M -an foo /dev/loop0 $ lvcreate -n fast -L 32M -an foo /dev/pmem0 $ lvconvert --type writecache --cachepool fast foo/main $ lvs -a foo -o+devices LV VG Attr LSize Origin Devices [fast] foo -wi------- 32.00m /dev/pmem0(0) main foo Cwi------- 128.00m [main_wcorig] main_wcorig(0) [main_wcorig] foo -wi------- 128.00m /dev/loop0(0) $ lvchange -ay foo/main $ dmsetup table foo-main_wcorig: 0 262144 linear 7:0 2048 foo-main: 0 262144 writecache p 253:4 253:3 4096 0 foo-fast: 0 65536 linear 259:0 2048 $ lvchange -an foo/main $ lvconvert --splitcache foo/main $ lvs -a foo -o+devices LV VG Attr LSize Devices fast foo -wi------- 32.00m /dev/pmem0(0) main foo -wi------- 128.00m /dev/loop0(0)
2018-08-27 22:53:09 +03:00
display_lvname(lv), type->name);
}
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
}
return ret;
}
/* Check if LV passes each rule specified in command definition. */
static int _check_lv_rules(struct cmd_context *cmd, struct logical_volume *lv)
{
char buf[64];
command: more static const declaration Use static const for declared arrays. Access to arrays through get_ functions().
2024-04-28 20:52:26 +03:00
const struct cmd_rule *rule;
const struct lv_type *lvtype = NULL;
coverity: add some initilizers Coverity cannot do a deeper analyzis so let's make just reports go away and initialize them to 0.
2017-11-07 22:54:51 +03:00
uint64_t lv_props_match_bits = 0, lv_props_unmatch_bits = 0;
uint64_t lv_types_match_bits = 0, lv_types_unmatch_bits = 0;
int opts_match_count = 0, opts_unmatch_count = 0;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
int lvt_enum;
int ret = 1;
int i;
lvconvert: use command defs for thin/cache/pool creation Everything related to thin and cache.
2016-12-07 23:30:57 +03:00
lvt_enum = get_lvt_enum(lv);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
if (lvt_enum)
lvtype = get_lv_type(lvt_enum);
for (i = 0; i < cmd->command->rule_count; i++) {
rule = &cmd->command->rules[i];
/*
* RULE: <conditions> INVALID|REQUIRE <checks>
*
* If all the conditions apply to the command+LV, then
* the checks are performed. If all conditions are zero
* (!opts_count, !lvt_bits, !lvp_bits), then the check
* is always performed.
*
* Conditions:
*
* 1. options (opts): if any of the specified options are set,
* then the checks may apply.
*
* 2. LV types (lvt_bits): if any of the specified LV types
* match the LV, then the checks may apply.
*
* 3. LV properties (lvp_bits): if all of the specified
* LV properties match the LV, then the checks may apply.
*
* If conditions 1, 2, 3 all pass, then the checks apply.
*
* Checks:
*
* 1. options (check_opts):
* INVALID: if any of the specified options are set,
* then the command fails.
* REQUIRE: if any of the specified options are not set,
* then the command fails.
*
* 2. LV types (check_lvt_bits):
* INVALID: if any of the specified LV types match the LV,
* then the command fails.
* REQUIRE: if none of the specified LV types match the LV,
* then the command fails.
*
* 3. LV properties (check_lvp_bits):
* INVALID: if any of the specified LV properties match
* the LV, then the command fails.
* REQUIRE: if any of the specified LV properties do not match
* the LV, then the command fails.
*/
if (rule->opts_count && !opt_in_list_is_set(cmd, rule->opts, rule->opts_count, NULL, NULL))
continue;
/* If LV matches one type in lvt_bits, this returns 1. */
if (rule->lvt_bits && !_lv_types_match(cmd, lv, rule->lvt_bits, NULL, NULL))
continue;
/* If LV matches all properties in lvp_bits, this returns 1. */
if (rule->lvp_bits && !_lv_props_match(cmd, lv, rule->lvp_bits, NULL, NULL))
continue;
/*
* Check the options, LV types, LV properties.
*/
command: futher move to single struct Refactor code to not allocate memory for rule->opts, instead use uint16_t array of MAX_RULE_OPTS within cmd_rule. Also print more info if array would not be enough (>= 8).
2024-05-11 01:42:49 +03:00
if (rule->check_opts_count)
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
opt_in_list_is_set(cmd, rule->check_opts, rule->check_opts_count,
&opts_match_count, &opts_unmatch_count);
if (rule->check_lvt_bits)
_lv_types_match(cmd, lv, rule->check_lvt_bits,
&lv_types_match_bits, &lv_types_unmatch_bits);
if (rule->check_lvp_bits)
_lv_props_match(cmd, lv, rule->check_lvp_bits,
&lv_props_match_bits, &lv_props_unmatch_bits);
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
/*
* Evaluate if the check results pass based on the rule.
* The options are checked again here because the previous
* option validation (during command matching) does not cover
* cases where the option is combined with conditions of LV types
* or properties.
*/
/* Fail if any invalid options are set. */
command: futher move to single struct Refactor code to not allocate memory for rule->opts, instead use uint16_t array of MAX_RULE_OPTS within cmd_rule. Also print more info if array would not be enough (>= 8).
2024-05-11 01:42:49 +03:00
if (rule->check_opts_count && (rule->rule == RULE_INVALID) && opts_match_count) {
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
memset(buf, 0, sizeof(buf));
opt_array_to_str(cmd, rule->check_opts, rule->check_opts_count, buf, sizeof(buf));
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s has invalid use of option %s.",
commands: improve error messages for rules Make the error messages more consistent, and use less code-centric wording.
2017-04-25 20:19:11 +03:00
display_lvname(lv), buf);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
ret = 0;
}
/* Fail if any required options are not set. */
command: futher move to single struct Refactor code to not allocate memory for rule->opts, instead use uint16_t array of MAX_RULE_OPTS within cmd_rule. Also print more info if array would not be enough (>= 8).
2024-05-11 01:42:49 +03:00
if (rule->check_opts_count && (rule->rule == RULE_REQUIRE) && opts_unmatch_count) {
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
memset(buf, 0, sizeof(buf));
opt_array_to_str(cmd, rule->check_opts, rule->check_opts_count, buf, sizeof(buf));
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s requires option %s.",
commands: improve error messages for rules Make the error messages more consistent, and use less code-centric wording.
2017-04-25 20:19:11 +03:00
display_lvname(lv), buf);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
ret = 0;
}
/* Fail if the LV matches any of the invalid LV types. */
if (rule->check_lvt_bits && (rule->rule == RULE_INVALID) && lv_types_match_bits) {
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
if (rule->opts_count)
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s uses options invalid with LV type %s.",
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
display_lvname(lv), lvtype ? lvtype->name : "unknown");
else
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s with invalid LV type %s.",
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
display_lvname(lv), lvtype ? lvtype->name : "unknown");
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
ret = 0;
}
/* Fail if the LV does not match any of the required LV types. */
if (rule->check_lvt_bits && (rule->rule == RULE_REQUIRE) && !lv_types_match_bits) {
memset(buf, 0, sizeof(buf));
tidy: Add missing underscores to statics.
2017-10-18 17:57:46 +03:00
_lvt_bits_to_str(rule->check_lvt_bits, buf, sizeof(buf));
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
if (rule->opts_count)
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s uses options that require LV types %s.",
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
display_lvname(lv), buf);
else
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s does not accept LV type %s. Required LV types are %s.",
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
display_lvname(lv), lvtype ? lvtype->name : "unknown", buf);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
ret = 0;
}
/* Fail if the LV matches any of the invalid LV properties. */
if (rule->check_lvp_bits && (rule->rule == RULE_INVALID) && lv_props_match_bits) {
memset(buf, 0, sizeof(buf));
tidy: Add missing underscores to statics.
2017-10-18 17:57:46 +03:00
_lvp_bits_to_str(lv_props_match_bits, buf, sizeof(buf));
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
if (rule->opts_count)
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s uses options that are invalid with LV properties: %s.",
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
display_lvname(lv), buf);
else
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s is invalid on LV with properties: %s.",
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
display_lvname(lv), buf);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
ret = 0;
}
/* Fail if the LV does not match any of the required LV properties. */
if (rule->check_lvp_bits && (rule->rule == RULE_REQUIRE) && lv_props_unmatch_bits) {
memset(buf, 0, sizeof(buf));
tidy: Add missing underscores to statics.
2017-10-18 17:57:46 +03:00
_lvp_bits_to_str(lv_props_unmatch_bits, buf, sizeof(buf));
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
if (rule->opts_count)
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s uses options that require LV properties: %s.",
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
display_lvname(lv), buf);
else
debug: print WARNING: Add WARNING: in front of log_warn() messages.
2023-07-15 11:57:37 +03:00
log_warn("WARNING: Command on LV %s requires LV with properties: %s.",
improve error messages when command rules fail When certain cmd def RULE's fail, the error messages can sometimes be confusing. This expands the error messages to help clarify why the rule failed, especially in cases where options are used incorrectly.
2017-09-20 18:51:52 +03:00
display_lvname(lv), buf);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
ret = 0;
}
}
return ret;
}
/*
* Return which arg position the given LV is at,
* where 1 represents the first position arg.
* When the first position arg is repeatable,
* return 1 for all.
*
* Return 0 when the command has no required
* position args. (optional position args are
* not considered.)
*/
static int _find_lv_arg_position(struct cmd_context *cmd, struct logical_volume *lv)
{
const char *sep, *lvname;
int i;
if (cmd->command->rp_count == 0)
return 0;
if (cmd->command->rp_count == 1)
return 1;
for (i = 0; i < cmd->position_argc; i++) {
if (i == cmd->command->rp_count)
break;
if (!val_bit_is_set(cmd->command->required_pos_args[i].def.val_bits, lv_VAL))
continue;
if ((sep = strstr(cmd->position_argv[i], "/")))
lvname = sep + 1;
else
lvname = cmd->position_argv[i];
if (!strcmp(lvname, lv->name))
return i + 1;
}
/*
* If the last position arg is an LV and this
* arg is beyond that position, then the last
* LV position arg is repeatable, so return
* that position.
*/
if (i == cmd->command->rp_count) {
int last_pos = cmd->command->rp_count;
if (val_bit_is_set(cmd->command->required_pos_args[last_pos-1].def.val_bits, lv_VAL))
return last_pos;
}
return 0;
}
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
int process_each_lv_in_vg(struct cmd_context *cmd, struct volume_group *vg,
struct dm_list *arg_lvnames, const struct dm_list *tags_in,
vgremove: Use process_each_lv_in_vg.
2014-10-07 19:45:45 +04:00
int stop_on_error,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct processing_handle *handle,
process_each_lv: add check_single_lv function The new check_single_lv() function is called prior to the existing process_single_lv(). If the check function returns 0, the LV will not be processed. The check_single_lv function is meant to be a standard method to validate the combination of specific command + specific LV, and decide if the combination is allowed. The check_single function can be used by anything that calls process_each_lv. As commands are migrated to take advantage of command definitions, each command definition gets its own entry point which calls process_each for itself, passing a pair of check_single/process_single functions which can be specific to the narrowly defined command def.
2016-11-29 21:00:15 +03:00
check_single_lv_fn_t check_single_lv,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
process_single_lv_fn_t process_single_lv)
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
{
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_report_t saved_log_report_state = log_get_report_state();
char lv_uuid[64] __attribute__((aligned(8)));
char vg_uuid[64] __attribute__((aligned(8)));
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
int ret_max = ECMD_PROCESSED;
int ret = 0;
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
int whole_selected = 0;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
int handle_supplied = handle != NULL;
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
unsigned process_lv;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
unsigned process_all = 0;
unsigned tags_supplied = 0;
unsigned lvargs_supplied = 0;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
int lv_is_named_arg;
int lv_arg_pos;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
struct lv_list *lvl;
struct dm_str_list *sl;
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
struct dm_list final_lvs;
struct lv_list *final_lvl;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
struct dm_list found_arg_lvnames;
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
struct glv_list *glvl, *tglvl;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
int do_report_ret_code = 1;
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
toollib: avoid repeated remove of online vg Call just once unlink after every deactivation of LV from VG.
2021-12-17 15:18:56 +03:00
cmd->online_vg_file_removed = 0;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_LV);
vg_uuid[0] = '\0';
if (!id_write_format(&vg->id, vg_uuid, sizeof(vg_uuid)))
stack;
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
dm_list_init(&final_lvs);
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
dm_list_init(&found_arg_lvnames);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
if (tags_in && !dm_list_empty(tags_in))
tags_supplied = 1;
if (arg_lvnames && !dm_list_empty(arg_lvnames))
lvargs_supplied = 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 && !(handle = init_processing_handle(cmd, NULL))) {
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
ret_max = ECMD_FAILED;
goto_out;
}
if (handle->internal_report_for_select && !handle->selection_handle &&
select: initialize selection handle for process_each_* fns with initial report type This is a followup patch for previous patchset that enables selection in process_each_* fns to fix an issue where field prefixes are not automatically used for fields in selection criteria. Use initial report type that matches the intention of each process_each_* functions: - _process_pvs_in_vg - PVS - process_each_vg - VGS - process_each_lv and process_each_lv_in_vg - LVS This is not normally needed for the selection handle init, BUT we would miss the field prefix matching, e.g. lvchange -ay -S 'name=lvol0' The "name" above would not work if we didn't initialize reporting with the LVS type at its start. If we pass proper init type, reporting code can deduce the prefix automatically ("lv_name" in this case). This report type is then changed further based on what selection criteria we have. When doing pure selection, not report output, the final report type is purely based on combination of this initial report type and report types of the fields used in selection criteria.
2015-02-10 15:46:37 +03:00
!init_selection_handle(cmd, handle, LVS)) {
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
ret_max = ECMD_FAILED;
goto_out;
}
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
/* Process all LVs in this VG if no restrictions given
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
* or if VG tags match. */
if ((!tags_supplied && !lvargs_supplied) ||
(tags_supplied && str_list_match_list(tags_in, &vg->tags, NULL)))
process_all = 1;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_group_and_group_id(vg->name, vg_uuid);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
dm_list_iterate_items(lvl, &vg->lvs) {
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
lv_uuid[0] = '\0';
if (!id_write_format(&lvl->lv->lvid.id[1], lv_uuid, sizeof(lv_uuid)))
stack;
log_set_report_object_name_and_id(lvl->lv->name, lv_uuid);
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
if (sigint_caught()) {
ret_max = ECMD_FAILED;
goto_out;
}
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
cleanup: more lv_is_ usage
2016-12-13 02:09:15 +03:00
if (lv_is_snapshot(lvl->lv))
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
continue;
/* Skip availability change for non-virt snaps when processing all LVs */
/* FIXME: pass process_all to process_single_lv() */
lv/vgchange: when refreshing whole vg skip snapshot When refreshing all LVs in a VG, skip processing of thick snapshots, since they will be refreshed through its origin LV. Should reduce some unnecessary ioctl().
2023-02-01 00:48:43 +03:00
if (process_all &&
(arg_is_set(cmd, activate_ARG) ||
arg_is_set(cmd, refresh_ARG)) &&
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
lv_is_cow(lvl->lv) && !lv_is_virtual_origin(origin_from_cow(lvl->lv)))
continue;
tools: Use arg_is_set instead of arg_count.
2016-06-22 00:24:52 +03:00
if (lv_is_virtual_origin(lvl->lv) && !arg_is_set(cmd, all_ARG)) {
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
if (lvargs_supplied &&
str_list_match_item(arg_lvnames, lvl->lv->name))
log_print_unless_silent("Ignoring virtual origin logical volume %s.",
display_lvname(lvl->lv));
continue;
}
/*
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
* Only let hidden LVs through if --all was used or the LVs
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
* were specifically named on the command line.
*/
activation: support activation of component LVs Occasionaly users may need to peek into 'component devices. Normally lvm2 does not let users activation component. This patch adds special mode where user can activate component LV in a 'read-only' mode i.e.: lvchange -ay vg/pool_tdata All devices can be deactivated with: lvchange -an vg | vgchange -an....
2018-02-28 19:16:17 +03:00
if (!lvargs_supplied && !lv_is_visible(lvl->lv) && !arg_is_set(cmd, all_ARG) &&
(!cmd->process_component_lvs || !lv_is_component(lvl->lv)))
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
continue;
toollib: skip processing the sanlock LV unless named or all This prevents 'lvremove vgname' from attempting to remove the hidden sanlock LV. Only vgremove should remove the hidden sanlock LV holding the sanlock locks.
2015-07-08 00:04:18 +03:00
/*
* Only let sanlock LV through if --all was used or if
* it is named on the command line.
*/
if (lv_is_lockd_sanlock_lv(lvl->lv)) {
tools: Use arg_is_set instead of arg_count.
2016-06-22 00:24:52 +03:00
if (arg_is_set(cmd, all_ARG) ||
toollib: skip processing the sanlock LV unless named or all This prevents 'lvremove vgname' from attempting to remove the hidden sanlock LV. Only vgremove should remove the hidden sanlock LV holding the sanlock locks.
2015-07-08 00:04:18 +03:00
(lvargs_supplied && str_list_match_item(arg_lvnames, lvl->lv->name))) {
log_very_verbose("Processing lockd_sanlock_lv %s/%s.", vg->name, lvl->lv->name);
} else {
continue;
}
}
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
/*
* process the LV if one of the following:
* - process_all is set
* - LV name matches a supplied LV name
* - LV tag matches a supplied LV tag
* - LV matches the selection
*/
process_lv = process_all;
if (lvargs_supplied && str_list_match_item(arg_lvnames, lvl->lv->name)) {
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
/* Remove LV from list of unprocessed LV names */
str_list_del(arg_lvnames, lvl->lv->name);
coverity: add missing error check for str_list_add Validate success.
2018-03-17 16:15:11 +03:00
if (!str_list_add(cmd->mem, &found_arg_lvnames, lvl->lv->name)) {
log_error("strlist allocation failed.");
ret_max = ECMD_FAILED;
goto out;
}
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
process_lv = 1;
}
if (!process_lv && tags_supplied && str_list_match_list(tags_in, &lvl->lv->tags, NULL))
process_lv = 1;
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
process_lv = process_lv && select_match_lv(cmd, handle, vg, lvl->lv) && _select_matches(handle);
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
if (!process_lv)
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
continue;
debug: display_lvname
2021-03-11 00:05:10 +03:00
log_very_verbose("Adding %s to the list of LVs to be processed.", display_lvname(lvl->lv));
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
toollib: use cmd mempool for list When creating a list in 'context of command' - use proper mempool. vg->vgmem is mempool related to VG metadata - and can be eventually locked read-only when VG struct is shared.
2016-01-21 15:18:11 +03:00
if (!(final_lvl = dm_pool_zalloc(cmd->mem, sizeof(struct lv_list)))) {
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
log_error("Failed to allocate final LV list item.");
ret_max = ECMD_FAILED;
debug: more stacktrace corrections Continue previous patch dropping some unneeded stack traces after printed log_error/warn messages.
2016-11-25 15:46:06 +03:00
goto out;
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
}
final_lvl->lv = lvl->lv;
toollib: prioritize processing thin-pool first When generating list of processed LV, add thin-pool to the head of the list, while other LVs are added on tail. This makes it easier when removing many thin volumes, to recognize easily when its thin-pool is also supposed to be removed.
2021-03-11 00:02:38 +03:00
if (lv_is_thin_pool(lvl->lv)) {
/* Add to the front of the list */
dm_list_add_h(&final_lvs, &final_lvl->list);
} else
dm_list_add(&final_lvs, &final_lvl->list);
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
}
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
scan: drop bcache and close fd for LV with stacked PV When a PV is stacked on an LV, the LV will be kept in bcache, and the open fd on the LV may interfere with processing the LV. So, drop/close a bcache fd for an LV before processing the LV.
2018-02-16 19:37:09 +03:00
/*
* If a PV is stacked on an LV, then the LV is kept open
* in bcache, and needs to be closed so the open fd doesn't
* interfere with processing the LV.
*/
label: cache dm device list Since we check for present DM devices - cache result for futher use of checking presence of such device. lvm2 uses cache result for label scan, but also when it tries to activate or deactivate LV - however only simple target 'striped' is reasonably supported. Use disable_dm_devs to be able to control when lv_info() get cache or uncached results. TODO: support more type, however this is getting very complicated.
2021-12-15 13:45:22 +03:00
label_scan_invalidate_lvs(cmd, &final_lvs);
scan: drop bcache and close fd for LV with stacked PV When a PV is stacked on an LV, the LV will be kept in bcache, and the open fd on the LV may interfere with processing the LV. So, drop/close a bcache fd for an LV before processing the LV.
2018-02-16 19:37:09 +03:00
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
dm_list_iterate_items(lvl, &final_lvs) {
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
lv_uuid[0] = '\0';
if (!id_write_format(&lvl->lv->lvid.id[1], lv_uuid, sizeof(lv_uuid)))
stack;
log_set_report_object_name_and_id(lvl->lv->name, lv_uuid);
toollib: restore command break support Fix regression caused by c9f021de0b4d2c873ef5b97d17c602d0380359fd. This commit actually transfered real-action (e.g. device removal) into the next loop which has however missed to check for break. So add check for break also there.
2016-01-21 15:19:27 +03:00
if (sigint_caught()) {
ret_max = ECMD_FAILED;
goto_out;
}
metadata: vg: add removed_lvs field to collect LVs which have been removed Do not keep dangling LVs if they're removed from the vg->lvs list and move them to vg->removed_lvs instead (this is actually similar to already existing vg->removed_pvs list, just it's for LVs now). Once we have this vg->removed_lvs list indexed so it's possible to do lookups for LVs quickly, we can remove the LV_REMOVED flag as that one won't be needed anymore - instead of checking the flag, we can directly check the vg->removed_lvs list if the LV is present there or not and to say if the LV is removed or not then. For now, we don't have this index, but it may be implemented in the future.
2015-03-23 15:32:00 +03:00
/*
* FIXME: Once we have index over vg->removed_lvs, check directly
* LV presence there and remove LV_REMOVE flag/lv_is_removed fn
* as they won't be needed anymore.
*/
metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing This avoids a problem in which we're using selection on LV list - we need to do the selection on initial state and not on any intermediary state as we process LVs one by one - some of the relations among LVs can be gone during this processing. For example, processing one LV can cause the other LVs to lose the relation to this LV and hence they're not selectable anymore with the original selection criteria as it would be if we did selection on inital state. A perfect example is with thin snapshots: $ lvs -o lv_name,origin,layout,role vg LV Origin Layout Role lvol1 thin,sparse public,origin,thinorigin,multithinorigin lvol2 lvol1 thin,sparse public,snapshot,thinsnapshot lvol3 lvol1 thin,sparse public,snapshot,thinsnapshot pool thin,pool private $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed The lvremove command above was supposed to remove lvol1 as well as all its snapshots which have origin=lvol1. It failed to do so, because once we removed the origin lvol1, the lvol2 and lvol3 which were snapshots before are not snapshots anymore - the relations change as we're processing these LVs one by one. If we do the selection first and then execute any concrete actions on these LVs (which is what this patch does), the behaviour is correct then - the selection is done on the *initial state*: $ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1' Logical volume "lvol1" successfully removed Logical volume "lvol2" successfully removed Logical volume "lvol3" successfully removed Similarly for all the other situations in which relations among LVs are being changed by processing the LVs one by one. This patch also introduces LV_REMOVED internal LV status flag to mark removed LVs so they're not processed further when we iterate over collected list of LVs to be processed. Previously, when we iterated directly over vg->lvs list to process the LVs, we relied on the fact that once the LV is removed, it is also removed from the vg->lvs list we're iterating over. But that was incorrect as we shouldn't remove LVs from the list during one iteration while we're iterating over that exact list (dm_list_iterate_items safe can handle only one removal at one iteration anyway, so it can't be used here).
2015-03-16 19:10:21 +03:00
if (lv_is_removed(lvl->lv))
continue;
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
lv_is_named_arg = str_list_match_item(&found_arg_lvnames, lvl->lv->name);
lv_arg_pos = _find_lv_arg_position(cmd, lvl->lv);
/*
* The command definition may include restrictions on the
* types and properties of LVs that can be processed.
*/
if (!_check_lv_types(cmd, lvl->lv, lv_arg_pos)) {
/* FIXME: include this result in report log? */
if (lv_is_named_arg) {
commands: improve error messages for rules Make the error messages more consistent, and use less code-centric wording.
2017-04-25 20:19:11 +03:00
log_error("Command not permitted on LV %s.", display_lvname(lvl->lv));
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
ret_max = ECMD_FAILED;
}
continue;
}
if (!_check_lv_rules(cmd, lvl->lv)) {
/* FIXME: include this result in report log? */
if (lv_is_named_arg) {
commands: improve error messages for rules Make the error messages more consistent, and use less code-centric wording.
2017-04-25 20:19:11 +03:00
log_error("Command not permitted on LV %s.", display_lvname(lvl->lv));
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
ret_max = ECMD_FAILED;
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
}
commands: new method for defining commands . Define a prototype for every lvm command. . Match every user command with one definition. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB ID: lvresize_by_pv DESC: Resize an LV by specified PV extents. FLAGS: SECONDARY_SYNTAX lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize a pool metadata SubLV by a specified size. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. usage/help output is also auto generated, so it is always in sync with the definitions. Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command. The prototype syntax used for help/man output includes required --option and positional args on the first line, and optional --option and positional args enclosed in [ ] on subsequent lines. command_name <required_opt_args> <required_pos_args> [ <optional_opt_args> ] [ <optional_pos_args> ] Command definitions that are not to be advertised/suggested have the flag SECONDARY_SYNTAX. These commands will not be printed in the normal help output. Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing per-command-name implementation functions. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition.
2016-08-12 23:52:18 +03:00
continue;
}
process_each_lv: add check_single_lv function The new check_single_lv() function is called prior to the existing process_single_lv(). If the check function returns 0, the LV will not be processed. The check_single_lv function is meant to be a standard method to validate the combination of specific command + specific LV, and decide if the combination is allowed. The check_single function can be used by anything that calls process_each_lv. As commands are migrated to take advantage of command definitions, each command definition gets its own entry point which calls process_each for itself, passing a pair of check_single/process_single functions which can be specific to the narrowly defined command def.
2016-11-29 21:00:15 +03:00
if (check_single_lv && !check_single_lv(cmd, lvl->lv, handle, lv_is_named_arg)) {
if (lv_is_named_arg)
ret_max = ECMD_FAILED;
continue;
}
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_very_verbose("Processing LV %s in VG %s.", lvl->lv->name, vg->name);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
ret = process_single_lv(cmd, lvl->lv, handle);
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
if (handle_supplied)
_update_selection_result(handle, &whole_selected);
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (ret != ECMD_PROCESSED)
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
stack;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
if (ret > ret_max)
ret_max = ret;
vgremove: Use process_each_lv_in_vg.
2014-10-07 19:45:45 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
if (stop_on_error && ret != ECMD_PROCESSED) {
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
do_report_ret_code = 0;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
goto_out;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
}
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
}
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
if (handle->include_historical_lvs && !tags_supplied) {
cleanup: use dm_list_empty Instant check for 'dm_list_size() == 0' without any size calc.
2021-10-01 15:30:49 +03:00
if (dm_list_empty(&_historical_lv.segments))
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
dm_list_add(&_historical_lv.segments, &_historical_lv_segment.list);
_historical_lv.vg = vg;
dm_list_iterate_items_safe(glvl, tglvl, &vg->historical_lvs) {
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
lv_uuid[0] = '\0';
if (!id_write_format(&glvl->glv->historical->lvid.id[1], lv_uuid, sizeof(lv_uuid)))
stack;
log_set_report_object_name_and_id(glvl->glv->historical->name, lv_uuid);
toolib: move sigint_caught Move the check for catched signal to the loop front. Currently not much usable - but we can improve it later.
2021-02-27 21:22:11 +03:00
if (sigint_caught()) {
ret_max = ECMD_FAILED;
goto_out;
}
toollib: do not process just created historical LV When executing process_each_lv_in_vg, we process live LVs first and after that, we process any historical LVs. In case we have just removed an LV, which also means we have just made it "historical" and so it appears as fresh item in vg->historical_lvs list, we have to skip it when we get to processing historical LVs inside the same process_each_lv_in_vg call. The simplest approach here, without introducing another LV list, is to simply mark such historical LVs as "fresh" directly in struct historical_logical_volume when we have just removed the original LV and created the historical LV for it. Then, we just need to check the flag when processing historical LVs and skip it if it is "fresh". When we read historical LVs out of metadata, they are marked as "not fresh" and so they can be processed as usual. This was mainly an issue in conjuction with -S|--select use: # lvmconfig --type diff metadata { record_lvs_history=1 } (In this example, a thin pool with lvol1 thin LV and lvol2 and lvol3 snapshots.) # lvs -H vg -o name,pool_lv,full_ancestors,full_descendants LV Pool FAncestors FDescendants lvol1 pool lvol2,lvol3 lvol2 pool lvol1 lvol3 lvol3 pool lvol2,lvol1 pool # lvremove -S 'name=lvol2' Logical volume "lvol2" successfully removed. Historical logical volume "lvol2" successfully removed. ...here, the historical LV lvol2 should not have been removed because we have just removed its original non-historical lvol2 and the fresh historical lvol2 must not be included in the same processing spree.
2022-10-12 15:41:58 +03:00
if (glvl->glv->historical->fresh)
continue;
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
process_lv = process_all;
if (lvargs_supplied &&
(sl = _str_list_match_item_with_prefix(arg_lvnames, HISTORICAL_LV_PREFIX, glvl->glv->historical->name))) {
str_list_del(arg_lvnames, glvl->glv->historical->name);
dm_list_del(&sl->list);
process_lv = 1;
}
toollib: fix segfault when handling selection with historical LVs When processing historical LVs inside process_each_lv_in_vg for selection, we need to use dummy "_historical_lv" for select_match_lv. This is because a historical LV is not an actual LV, but only a tiny representation with subset of original properties that we recorded (name, uuid...). To use the same processing functions we use for full-fledged non-historical LVs, we need to use the prefilled "_historical_lv" structure which has all the other missing properties hard-coded.
2022-05-05 12:02:32 +03:00
_historical_lv.this_glv = glvl->glv;
_historical_lv.name = glvl->glv->historical->name;
process_lv = process_lv && select_match_lv(cmd, handle, vg, &_historical_lv) && _select_matches(handle);
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
if (!process_lv)
continue;
log_very_verbose("Processing historical LV %s in VG %s.", glvl->glv->historical->name, vg->name);
cov: annotate already validated lv name
2024-05-30 15:40:45 +03:00
/* coverity[format_string_injection] lv name is already validated */
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
ret = process_single_lv(cmd, &_historical_lv, handle);
if (handle_supplied)
_update_selection_result(handle, &whole_selected);
if (ret != ECMD_PROCESSED)
stack;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret);
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
if (ret > ret_max)
ret_max = ret;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
if (stop_on_error && ret != ECMD_PROCESSED) {
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
do_report_ret_code = 0;
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
goto_out;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
}
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
}
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
toollib: honour '-H|--history' switch while executing process_each_lv_in_vg When processing LVs in a VG and when the -H|--history switch is used, make process_each_lv_in_vg to iterate over historical volumes too. For each historical LV, we use dummy struct logical_volume instance with the "this_glv" reference set to a wrapper over proper struct historical_logical_volume representation. This makes it possible to process historical LVs just like normal live LVs (though a dummy one without any segments and all the other fields zeroed and blank) and it also allows for using all historical LV related information via lv->this_glv->historical reference. One can use a simple call to lv_is_historical to make a difference between live and historical LV in all the code that is called by process_each_* fns.
2016-03-01 17:23:05 +03:00
}
lv_remove: reduce commits for removed LVs This patch postpones update of lvm metadata for each removed LV for later moment depending on LV type. It also queues messages to be printed after such write & commit. As such there is some change in the behavior - although before prompt we do make write&commit happens automatically in some other error case we rather keep 'existing' state - so there could be difference in amount of removed & commited LVs. IMHO introduce logic is slightly better and more save. But some cases still need the early commit - i.e. thin-removal and fixing this needs some more thinking. TODO: improve removal at least with the case of the whole thin-pool. i.e. we can simply recognize removal of 'all LVs/whole VG'.
2021-03-05 18:21:50 +03:00
if (vg->needs_write_and_commit && (ret_max == ECMD_PROCESSED) &&
(!vg_write(vg) || !vg_commit(vg)))
lvremove: correct return code Need to return ECMD_FAILED from toollib code. Add missing stack traces.
2021-03-08 22:24:04 +03:00
ret_max = ECMD_FAILED;
lvremove: backup at the end of loop Taking backup with each removed LV is slowing down the process considerable and is largerly uneeded. We are supposed to take backup only on significant points and making sure the backup is correct when the command is finished. TODO: check how many other commands can be improved.
2021-02-26 03:01:29 +03:00
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
if (lvargs_supplied) {
/*
* FIXME: lvm supports removal of LV with all its dependencies
* this leads to miscalculation that depends on the order of args.
*/
dm_list_iterate_items(sl, arg_lvnames) {
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(sl->str, NULL);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
log_error("Failed to find logical volume \"%s/%s\"",
vg->name, sl->str);
if (ret_max < ECMD_FAILED)
ret_max = ECMD_FAILED;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret_max);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
}
}
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
do_report_ret_code = 0;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
out:
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
if (do_report_ret_code)
report_log_ret_code(ret_max);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
log_set_report_object_group_and_group_id(NULL, NULL);
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
if (!handle_supplied)
cleanup: remove deallocate_handle_root arg from destroy_procesing_handle fnw
2015-02-13 12:42:21 +03:00
destroy_processing_handle(cmd, handle);
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
else
_set_final_selection_result(handle, whole_selected);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_restore_report_state(saved_log_report_state);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
return ret_max;
}
/*
* If arg is tag, add it to arg_tags
* else the arg is either vgname or vgname/lvname:
* - add the vgname of each arg to arg_vgnames
* - if arg has no lvname, add just vgname arg_lvnames,
* it represents all lvs in the vg
* - if arg has lvname, add vgname/lvname to arg_lvnames
*/
static int _get_arg_lvnames(struct cmd_context *cmd,
int argc, char **argv,
lvconvert: use process_each_lv In the same way that process_each_vg() can be passed a single VG name to process, also allow process_each_lv() to be passed a single VG name and LV name to process.
2016-05-23 21:42:17 +03:00
const char *one_vgname, const char *one_lvname,
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
struct dm_list *arg_vgnames,
struct dm_list *arg_lvnames,
struct dm_list *arg_tags)
{
int opt = 0;
int ret_max = ECMD_PROCESSED;
char *vglv;
size_t vglv_sz;
const char *vgname;
const char *lv_name;
const char *tmp_lv_name;
toollib: Remove unused functions from header file.
2014-10-06 18:22:01 +04:00
const char *vgname_def;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
unsigned dev_dir_found;
lvconvert: use process_each_lv In the same way that process_each_vg() can be passed a single VG name to process, also allow process_each_lv() to be passed a single VG name and LV name to process.
2016-05-23 21:42:17 +03:00
if (one_vgname) {
if (!str_list_add(cmd->mem, arg_vgnames,
dm_pool_strdup(cmd->mem, one_vgname))) {
log_error("strlist allocation failed.");
return ECMD_FAILED;
}
if (!one_lvname) {
if (!str_list_add(cmd->mem, arg_lvnames,
dm_pool_strdup(cmd->mem, one_vgname))) {
log_error("strlist allocation failed.");
return ECMD_FAILED;
}
} else {
vglv_sz = strlen(one_vgname) + strlen(one_lvname) + 2;
if (!(vglv = dm_pool_alloc(cmd->mem, vglv_sz)) ||
dm_snprintf(vglv, vglv_sz, "%s/%s", one_vgname, one_lvname) < 0) {
log_error("vg/lv string alloc failed.");
return ECMD_FAILED;
}
if (!str_list_add(cmd->mem, arg_lvnames, vglv)) {
log_error("strlist allocation failed.");
return ECMD_FAILED;
}
}
return ret_max;
}
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
for (; opt < argc; opt++) {
lv_name = argv[opt];
dev_dir_found = 0;
/* Do we have a tag or vgname or lvname? */
vgname = lv_name;
if (*vgname == '@') {
if (!validate_tag(vgname + 1)) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("Skipping invalid tag %s.", vgname);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
continue;
}
if (!str_list_add(cmd->mem, arg_tags,
dm_pool_strdup(cmd->mem, vgname + 1))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("strlist allocation failed.");
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
return ECMD_FAILED;
}
continue;
}
/* FIXME Jumbled parsing */
vgname = skip_dev_dir(cmd, vgname, &dev_dir_found);
if (*vgname == '/') {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("\"%s\": Invalid path for Logical Volume.",
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
argv[opt]);
if (ret_max < ECMD_FAILED)
ret_max = ECMD_FAILED;
continue;
}
lv_name = vgname;
if ((tmp_lv_name = strchr(vgname, '/'))) {
/* Must be an LV */
lv_name = tmp_lv_name;
while (*lv_name == '/')
lv_name++;
if (!(vgname = extract_vgname(cmd, vgname))) {
if (ret_max < ECMD_FAILED) {
stack;
ret_max = ECMD_FAILED;
}
continue;
}
} else if (!dev_dir_found &&
toollib: Remove unused functions from header file.
2014-10-06 18:22:01 +04:00
(vgname_def = _default_vgname(cmd)))
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
vgname = vgname_def;
else
lv_name = NULL;
if (!str_list_add(cmd->mem, arg_vgnames,
dm_pool_strdup(cmd->mem, vgname))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("strlist allocation failed.");
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
return ECMD_FAILED;
}
if (!lv_name) {
if (!str_list_add(cmd->mem, arg_lvnames,
dm_pool_strdup(cmd->mem, vgname))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("strlist allocation failed.");
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
return ECMD_FAILED;
}
} else {
vglv_sz = strlen(vgname) + strlen(lv_name) + 2;
if (!(vglv = dm_pool_alloc(cmd->mem, vglv_sz)) ||
dm_snprintf(vglv, vglv_sz, "%s/%s", vgname, lv_name) < 0) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("vg/lv string alloc failed.");
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
return ECMD_FAILED;
}
if (!str_list_add(cmd->mem, arg_lvnames, vglv)) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("strlist allocation failed.");
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
return ECMD_FAILED;
}
}
}
return ret_max;
}
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
/*
lvconvert: fixing extraction of vgname Correction to function for extracting vgname out of lvconvert parameters. Avoid repeating some checks. Add code to handle generic options which may provide vgname in its argument and compare them all so they match to a single vgname (otherwise it's a error). Extract default (envvar) vgname only when no position nor optional vgname is found. Fixing regression instroduce with patchset started with commit: 1e2420bca85da9a37570871cd70192e9ae831786 (2.02.169)
2017-10-24 15:56:42 +03:00
* Finding vgname/lvname to process.
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
*
lvconvert: fixing extraction of vgname Correction to function for extracting vgname out of lvconvert parameters. Avoid repeating some checks. Add code to handle generic options which may provide vgname in its argument and compare them all so they match to a single vgname (otherwise it's a error). Extract default (envvar) vgname only when no position nor optional vgname is found. Fixing regression instroduce with patchset started with commit: 1e2420bca85da9a37570871cd70192e9ae831786 (2.02.169)
2017-10-24 15:56:42 +03:00
* When the position arg is a single name without any '/'
* it is treated as an LV name (leaving the VG unknown).
* Other option values, or env var, must be searched for a VG name.
* If one of the option values contains a vgname/lvname value,
* then the VG name is extracted and used for the LV position arg.
* Or, if the env var has the VG name, that is used.
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
*
* Other option values that are searched for a VG name are:
lvconvert: fixing extraction of vgname Correction to function for extracting vgname out of lvconvert parameters. Avoid repeating some checks. Add code to handle generic options which may provide vgname in its argument and compare them all so they match to a single vgname (otherwise it's a error). Extract default (envvar) vgname only when no position nor optional vgname is found. Fixing regression instroduce with patchset started with commit: 1e2420bca85da9a37570871cd70192e9ae831786 (2.02.169)
2017-10-24 15:56:42 +03:00
* --thinpool, --cachepool, --poolmetadata.
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
*
* . command vg/lv1
* . add vg to arg_vgnames
* . add vg/lv1 to arg_lvnames
*
* command lv1
commands: use existing vg/lv name parsing functions inside the new lv arg parsing function. This includes getting the VG name from the env var, and some added checks on the format of the vg/lv string.
2017-02-16 00:06:52 +03:00
* . error: no vg name (unless LVM_VG_NAME)
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
*
commands: use existing vg/lv name parsing functions inside the new lv arg parsing function. This includes getting the VG name from the env var, and some added checks on the format of the vg/lv string.
2017-02-16 00:06:52 +03:00
* command --option=vg/lv1 vg/lv2
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
* . verify both vg names match
* . add vg to arg_vgnames
* . add vg/lv2 to arg_lvnames
*
commands: use existing vg/lv name parsing functions inside the new lv arg parsing function. This includes getting the VG name from the env var, and some added checks on the format of the vg/lv string.
2017-02-16 00:06:52 +03:00
* command --option=lv1 lv2
* . error: no vg name (unless LVM_VG_NAME)
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
*
commands: use existing vg/lv name parsing functions inside the new lv arg parsing function. This includes getting the VG name from the env var, and some added checks on the format of the vg/lv string.
2017-02-16 00:06:52 +03:00
* command --option=vg/lv1 lv2
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
* . add vg to arg_vgnames
* . add vg/lv2 to arg_lvnames
*
commands: use existing vg/lv name parsing functions inside the new lv arg parsing function. This includes getting the VG name from the env var, and some added checks on the format of the vg/lv string.
2017-02-16 00:06:52 +03:00
* command --option=lv1 vg/lv2
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
* . add vg to arg_vgnames
* . add vg/lv2 to arg_lvnames
*/
static int _get_arg_lvnames_using_options(struct cmd_context *cmd,
int argc, char **argv,
struct dm_list *arg_vgnames,
struct dm_list *arg_lvnames,
struct dm_list *arg_tags)
{
lvconvert: fixing extraction of vgname Correction to function for extracting vgname out of lvconvert parameters. Avoid repeating some checks. Add code to handle generic options which may provide vgname in its argument and compare them all so they match to a single vgname (otherwise it's a error). Extract default (envvar) vgname only when no position nor optional vgname is found. Fixing regression instroduce with patchset started with commit: 1e2420bca85da9a37570871cd70192e9ae831786 (2.02.169)
2017-10-24 15:56:42 +03:00
/* Array with args which may provide vgname */
static const unsigned _opts_with_vgname[] = {
cachepool_ARG, poolmetadata_ARG, thinpool_ARG
};
unsigned i;
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
const char *pos_name = NULL;
const char *arg_name = NULL;
const char *pos_vgname = NULL;
const char *opt_vgname = NULL;
const char *pos_lvname = NULL;
const char *use_vgname = NULL;
char *vglv;
size_t vglv_sz;
if (argc != 1) {
log_error("One LV position arg is required.");
return ECMD_FAILED;
}
if (!(pos_name = dm_pool_strdup(cmd->mem, argv[0]))) {
log_error("string alloc failed.");
return ECMD_FAILED;
}
if (*pos_name == '@') {
if (!validate_tag(pos_name + 1)) {
log_error("Skipping invalid tag %s.", pos_name);
return ECMD_FAILED;
}
if (!str_list_add(cmd->mem, arg_tags,
dm_pool_strdup(cmd->mem, pos_name + 1))) {
log_error("strlist allocation failed.");
return ECMD_FAILED;
}
return ECMD_PROCESSED;
}
lvconvert: fixing extraction of vgname Correction to function for extracting vgname out of lvconvert parameters. Avoid repeating some checks. Add code to handle generic options which may provide vgname in its argument and compare them all so they match to a single vgname (otherwise it's a error). Extract default (envvar) vgname only when no position nor optional vgname is found. Fixing regression instroduce with patchset started with commit: 1e2420bca85da9a37570871cd70192e9ae831786 (2.02.169)
2017-10-24 15:56:42 +03:00
if (strchr(pos_name, '/')) {
commands: use existing vg/lv name parsing functions inside the new lv arg parsing function. This includes getting the VG name from the env var, and some added checks on the format of the vg/lv string.
2017-02-16 00:06:52 +03:00
/*
* This splits pos_name 'x/y' into pos_vgname 'x' and pos_lvname 'y'
* It skips repeated '/', e.g. x//y
* It also checks and fails for extra '/', e.g. x/y/z
*/
lvconvert: fixing extraction of vgname Correction to function for extracting vgname out of lvconvert parameters. Avoid repeating some checks. Add code to handle generic options which may provide vgname in its argument and compare them all so they match to a single vgname (otherwise it's a error). Extract default (envvar) vgname only when no position nor optional vgname is found. Fixing regression instroduce with patchset started with commit: 1e2420bca85da9a37570871cd70192e9ae831786 (2.02.169)
2017-10-24 15:56:42 +03:00
if (!(pos_vgname = _extract_vgname(cmd, pos_name, &pos_lvname)))
return_0;
use_vgname = pos_vgname;
} else
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
pos_lvname = pos_name;
lvconvert: fixing extraction of vgname Correction to function for extracting vgname out of lvconvert parameters. Avoid repeating some checks. Add code to handle generic options which may provide vgname in its argument and compare them all so they match to a single vgname (otherwise it's a error). Extract default (envvar) vgname only when no position nor optional vgname is found. Fixing regression instroduce with patchset started with commit: 1e2420bca85da9a37570871cd70192e9ae831786 (2.02.169)
2017-10-24 15:56:42 +03:00
/* Go through the list of options which can provide vgname */
for (i = 0; i < DM_ARRAY_SIZE(_opts_with_vgname); ++i) {
if ((arg_name = arg_str_value(cmd, _opts_with_vgname[i], NULL)) &&
strchr(arg_name, '/')) {
/* Combined VG/LV */
/* Don't care about opt lvname, only extract vgname. */
if (!(opt_vgname = _extract_vgname(cmd, arg_name, NULL)))
return_0;
/* Compare with already known vgname */
if (use_vgname) {
if (strcmp(use_vgname, opt_vgname)) {
log_error("VG name mismatch from %s arg (%s) and option arg (%s).",
pos_vgname ? "position" : "option",
use_vgname, opt_vgname);
return ECMD_FAILED;
}
} else
use_vgname = opt_vgname;
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
}
}
lvconvert: fixing extraction of vgname Correction to function for extracting vgname out of lvconvert parameters. Avoid repeating some checks. Add code to handle generic options which may provide vgname in its argument and compare them all so they match to a single vgname (otherwise it's a error). Extract default (envvar) vgname only when no position nor optional vgname is found. Fixing regression instroduce with patchset started with commit: 1e2420bca85da9a37570871cd70192e9ae831786 (2.02.169)
2017-10-24 15:56:42 +03:00
/* VG not specified as position nor as optional arg, so check for default VG */
if (!use_vgname && !(use_vgname = _default_vgname(cmd))) {
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
log_error("Cannot find VG name for LV %s.", pos_lvname);
return ECMD_FAILED;
}
if (!str_list_add(cmd->mem, arg_vgnames, dm_pool_strdup(cmd->mem, use_vgname))) {
log_error("strlist allocation failed.");
return ECMD_FAILED;
}
vglv_sz = strlen(use_vgname) + strlen(pos_lvname) + 2;
if (!(vglv = dm_pool_alloc(cmd->mem, vglv_sz)) ||
dm_snprintf(vglv, vglv_sz, "%s/%s", use_vgname, pos_lvname) < 0) {
log_error("vg/lv string alloc failed.");
return ECMD_FAILED;
}
if (!str_list_add(cmd->mem, arg_lvnames, vglv)) {
log_error("strlist allocation failed.");
return ECMD_FAILED;
}
return ECMD_PROCESSED;
}
vgs, lvs: ignore error if VG is removed If a VG is removed between the time that 'vgs' or 'lvs' (with no args) creates the list of VGs and the time that it reads the VG to process it, then ignore the removed VG; don't report an error that it could not be found, since it wasn't named by the command.
2015-10-27 18:52:01 +03:00
static int _process_lv_vgnameid_list(struct cmd_context *cmd, uint32_t read_flags,
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
struct dm_list *vgnameids_to_process,
struct dm_list *arg_vgnames,
struct dm_list *arg_lvnames,
struct dm_list *arg_tags,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct processing_handle *handle,
process_each_lv: add check_single_lv function The new check_single_lv() function is called prior to the existing process_single_lv(). If the check function returns 0, the LV will not be processed. The check_single_lv function is meant to be a standard method to validate the combination of specific command + specific LV, and decide if the combination is allowed. The check_single function can be used by anything that calls process_each_lv. As commands are migrated to take advantage of command definitions, each command definition gets its own entry point which calls process_each for itself, passing a pair of check_single/process_single functions which can be specific to the narrowly defined command def.
2016-11-29 21:00:15 +03:00
check_single_lv_fn_t check_single_lv,
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
process_single_lv_fn_t process_single_lv)
{
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_report_t saved_log_report_state = log_get_report_state();
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
char uuid[64] __attribute__((aligned(8)));
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
struct volume_group *vg;
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
struct volume_group *error_vg = NULL;
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
struct vgnameid_list *vgnl;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
struct dm_str_list *sl;
struct dm_list *tags_arg;
struct dm_list lvnames;
coverity: fix missing initialization ... Using uninitialized value "lockd_state" when calling "lockd_vg" (even though lockd_vg assigns 0 to the lockd_state, but it looks at previous state of lockd_state just before that so we need to have that properly initialized!) libdm/libdm-report.c:2934: uninit_use_in_call: Using uninitialized value "tm". Field "tm.tm_gmtoff" is uninitialized when calling "_get_final_time". daemons/lvmlockd/lvmlockctl.c:273: uninit_use_in_call: Using uninitialized element of array "r_name" when calling "format_info_r_action". (just added FIXME as this looks unfinished?)
2015-07-08 15:53:23 +03:00
uint32_t lockd_state = 0;
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
uint32_t error_flags = 0;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
const char *vg_name;
const char *vg_uuid;
const char *vgn;
const char *lvn;
int ret_max = ECMD_PROCESSED;
int ret;
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
int skip;
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
int notfound;
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
int is_lockd;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
int do_report_ret_code = 1;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_VG);
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
dm_list_iterate_items(vgnl, vgnameids_to_process) {
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
vg_name = vgnl->vg_name;
vg_uuid = vgnl->vgid;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
skip = 0;
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
notfound = 0;
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
is_lockd = lvmcache_vg_is_lockd_type(cmd, vg_name, vg_uuid);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
uuid[0] = '\0';
if (vg_uuid && !id_write_format((const struct id*)vg_uuid, uuid, sizeof(uuid)))
stack;
log_set_report_object_name_and_id(vg_name, uuid);
if (sigint_caught()) {
ret_max = ECMD_FAILED;
goto_out;
}
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
/*
* arg_lvnames contains some elements that are just "vgname"
* which means process all lvs in the vg. Other elements
* are "vgname/lvname" which means process only the select
* lvs in the vg.
*/
tags_arg = arg_tags;
dm_list_init(&lvnames); /* LVs to be processed in this VG */
dm_list_iterate_items(sl, arg_lvnames) {
vgn = sl->str;
lvn = strchr(vgn, '/');
if (!lvn && !strcmp(vgn, vg_name)) {
/* Process all LVs in this VG */
tags_arg = NULL;
dm_list_init(&lvnames);
break;
}
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
if (lvn && !strncmp(vgn, vg_name, strlen(vg_name)) &&
strlen(vg_name) == (size_t) (lvn - vgn)) {
if (!str_list_add(cmd->mem, &lvnames,
dm_pool_strdup(cmd->mem, lvn + 1))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("strlist allocation failed.");
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
ret_max = ECMD_FAILED;
goto out;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
}
}
}
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
log_very_verbose("Processing VG %s %s", vg_name, vg_uuid ? uuid : "");
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
do_lockd:
if (is_lockd && !lockd_vg(cmd, vg_name, NULL, 0, &lockd_state)) {
Add lvmlockd
2015-03-05 23:00:44 +03:00
ret_max = ECMD_FAILED;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret_max);
Add lvmlockd
2015-03-05 23:00:44 +03:00
continue;
}
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
vg = vg_read(cmd, vg_name, vg_uuid, read_flags, lockd_state, &error_flags, &error_vg);
if (_ignore_vg(cmd, error_flags, error_vg, vg_name, arg_vgnames, read_flags, &skip, &notfound)) {
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
stack;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
ret_max = ECMD_FAILED;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret_max);
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
if (error_vg)
unlock_and_release_vg(cmd, error_vg, vg_name);
Add lvmlockd
2015-03-05 23:00:44 +03:00
goto endvg;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
}
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
if (error_vg)
unlock_and_release_vg(cmd, error_vg, vg_name);
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
if (skip || notfound)
Add lvmlockd
2015-03-05 23:00:44 +03:00
goto endvg;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
if (!is_lockd && vg_is_shared(vg)) {
/* The lock_type changed since label_scan, won't really occur in practice. */
log_debug("Repeat lock and read for local to shared vg");
unlock_and_release_vg(cmd, vg, vg_name);
is_lockd = 1;
goto do_lockd;
}
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
ret = process_each_lv_in_vg(cmd, vg, &lvnames, tags_arg, 0,
process_each_lv: add check_single_lv function The new check_single_lv() function is called prior to the existing process_single_lv(). If the check function returns 0, the LV will not be processed. The check_single_lv function is meant to be a standard method to validate the combination of specific command + specific LV, and decide if the combination is allowed. The check_single function can be used by anything that calls process_each_lv. As commands are migrated to take advantage of command definitions, each command definition gets its own entry point which calls process_each for itself, passing a pair of check_single/process_single functions which can be specific to the narrowly defined command def.
2016-11-29 21:00:15 +03:00
handle, check_single_lv, process_single_lv);
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (ret != ECMD_PROCESSED)
stack;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
if (ret > ret_max)
ret_max = ret;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
Remove checking for locked VGs A few places were calling a function to check if a VG lock was held. The only place it was actually needed is for pvcreate which wants to do its own locking (and scanning) around process_each_pv. The locking/scanning exceptions for pvcreate in process_each_pv/vg_read can be enabled by just passing a couple of flags instead of checking if the VG is already locked. This also means that these special cases won't be enabled unknowingly in other places where they shouldn't be used.
2018-06-11 20:25:52 +03:00
unlock_vg(cmd, vg, vg_name);
Add lvmlockd
2015-03-05 23:00:44 +03:00
endvg:
release_vg(vg);
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
if (is_lockd && !lockd_vg(cmd, vg_name, "un", 0, &lockd_state))
lockd: check for failing unlock Avoid ignoring unlocking error.
2015-08-18 12:46:42 +03:00
stack;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
}
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
do_report_ret_code = 0;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
out:
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
if (do_report_ret_code)
report_log_ret_code(ret_max);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_restore_report_state(saved_log_report_state);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
return ret_max;
}
/*
* Call process_single_lv() for each LV selected by the command line arguments.
*/
lvconvert: use process_each_lv In the same way that process_each_vg() can be passed a single VG name to process, also allow process_each_lv() to be passed a single VG name and LV name to process.
2016-05-23 21:42:17 +03:00
int process_each_lv(struct cmd_context *cmd,
int argc, char **argv,
const char *one_vgname, const char *one_lvname,
uint32_t read_flags,
struct processing_handle *handle,
process_each_lv: add check_single_lv function The new check_single_lv() function is called prior to the existing process_single_lv(). If the check function returns 0, the LV will not be processed. The check_single_lv function is meant to be a standard method to validate the combination of specific command + specific LV, and decide if the combination is allowed. The check_single function can be used by anything that calls process_each_lv. As commands are migrated to take advantage of command definitions, each command definition gets its own entry point which calls process_each for itself, passing a pair of check_single/process_single functions which can be specific to the narrowly defined command def.
2016-11-29 21:00:15 +03:00
check_single_lv_fn_t check_single_lv,
lvconvert: use process_each_lv In the same way that process_each_vg() can be passed a single VG name to process, also allow process_each_lv() to be passed a single VG name and LV name to process.
2016-05-23 21:42:17 +03:00
process_single_lv_fn_t process_single_lv)
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
{
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_report_t saved_log_report_state = log_get_report_state();
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
int handle_supplied = handle != NULL;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
struct dm_list arg_tags; /* str_list */
struct dm_list arg_vgnames; /* str_list */
struct dm_list arg_lvnames; /* str_list */
struct dm_list vgnameids_on_system; /* vgnameid_list */
struct dm_list vgnameids_to_process; /* vgnameid_list */
command struct: remove command name refs Change run time access to the command_name struct cmd->cname instead of indirectly through cmd->command->cname. This removes the two run time fields from struct command.
2017-01-14 00:08:51 +03:00
int enable_all_vgs = (cmd->cname->flags & ALL_VGS_IS_DEFAULT);
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
int process_all_vgs_on_system = 0;
int ret_max = ECMD_PROCESSED;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
int ret;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_LV);
Add lvmlockd
2015-03-05 23:00:44 +03:00
/* Disable error in vg_read so we can print it from ignore_vg. */
cmd->vg_read_print_access_error = 0;
system_id: remove unwanted foreign error for some commands Commands that can never use foreign VGs begin with cmd->error_foreign_vgs = 1. This tells the vg_read lib layer to print an error as soon as a foreign VG is read. The toollib process_each layer also prints an error if a foreign VG is read, but is more selective about it. It won't print an error if the command did not explicitly name the foreign VG. We want to silently ignore foreign VGs unless a command attempts to use one explicitly. So, foreign VG errors are printed from two different layers: vg_read (lower layer) and process_each (upper layer). Commands that use toollib process_each, only want errors from the process_each layer, not from both layers. So, process_each disables the lower layer vg_read error message by setting error_foreign_vgs = 0. Commands that do not use toollib process_each, want errors from the vg_read layer, otherwise they would get no error message. The original cmd->error_foreign_vgs setting enables this error. (Commands that are allowed to operate on foreign VGs always begin with cmd->error_foreign_vgs = 0, and all the commands in this group use toollib process_each with the selective error reporting.)
2015-02-27 01:06:32 +03:00
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
dm_list_init(&arg_tags);
dm_list_init(&arg_vgnames);
dm_list_init(&arg_lvnames);
dm_list_init(&vgnameids_on_system);
dm_list_init(&vgnameids_to_process);
/*
* Find any LVs, VGs or tags explicitly provided on the command line.
*/
lvconvert: use cmd_context variable Do not modify flags field from 'strcut command_name' and instead control this via cmd_context get_vgname_from_options. Flag GET_VGNAME_FROM_OPTIONS is currently used only by lvconvert.
2024-04-28 19:01:33 +03:00
if (cmd->get_vgname_from_options)
toollib: find VG name in option values when needed
2016-12-09 22:30:42 +03:00
ret = _get_arg_lvnames_using_options(cmd, argc, argv, &arg_vgnames, &arg_lvnames, &arg_tags);
else
ret = _get_arg_lvnames(cmd, argc, argv, one_vgname, one_lvname, &arg_vgnames, &arg_lvnames, &arg_tags);
if (ret != ECMD_PROCESSED) {
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ret;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
goto_out;
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
}
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
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 && !(handle = init_processing_handle(cmd, NULL))) {
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ECMD_FAILED;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
goto_out;
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
}
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
if (handle->internal_report_for_select && !handle->selection_handle &&
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
!init_selection_handle(cmd, handle, LVS)) {
ret_max = ECMD_FAILED;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
goto_out;
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
}
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
/*
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
* Process all VGs on the system when:
* . tags are specified and all VGs need to be read to
* look for matching tags.
* . no VG names are specified and the command defaults
* to processing all VGs when none are specified.
* . no VG names are specified and the select option needs
* resolving.
*/
toollib: avoid repeated lvmetad vg_lookup In process_each_{vg,lv,pv} when no vgname args are given, the first step is to get a list of all vgid/vgname on the system. This is exactly what lvmetad returns from a vg_list request. The current code is doing a vg_lookup on each VG after the vg_list and populating lvmcache with the info for each VG. These preliminary vg_lookup's are unnecessary, because they will be done again when the processing functions call vg_read. This patch eliminates the initial round of vg_lookup's, which can roughly cut in half the number of lvmetad requests and save a lot of extra work.
2015-05-06 00:24:50 +03:00
if (!dm_list_empty(&arg_tags))
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
process_all_vgs_on_system = 1;
toollib: avoid repeated lvmetad vg_lookup In process_each_{vg,lv,pv} when no vgname args are given, the first step is to get a list of all vgid/vgname on the system. This is exactly what lvmetad returns from a vg_list request. The current code is doing a vg_lookup on each VG after the vg_list and populating lvmcache with the info for each VG. These preliminary vg_lookup's are unnecessary, because they will be done again when the processing functions call vg_read. This patch eliminates the initial round of vg_lookup's, which can roughly cut in half the number of lvmetad requests and save a lot of extra work.
2015-05-06 00:24:50 +03:00
else if (dm_list_empty(&arg_vgnames) && enable_all_vgs)
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
process_all_vgs_on_system = 1;
toollib: avoid repeated lvmetad vg_lookup In process_each_{vg,lv,pv} when no vgname args are given, the first step is to get a list of all vgid/vgname on the system. This is exactly what lvmetad returns from a vg_list request. The current code is doing a vg_lookup on each VG after the vg_list and populating lvmcache with the info for each VG. These preliminary vg_lookup's are unnecessary, because they will be done again when the processing functions call vg_read. This patch eliminates the initial round of vg_lookup's, which can roughly cut in half the number of lvmetad requests and save a lot of extra work.
2015-05-06 00:24:50 +03:00
else if (dm_list_empty(&arg_vgnames) && handle->internal_report_for_select)
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
process_all_vgs_on_system = 1;
toollib: avoid repeated lvmetad vg_lookup In process_each_{vg,lv,pv} when no vgname args are given, the first step is to get a list of all vgid/vgname on the system. This is exactly what lvmetad returns from a vg_list request. The current code is doing a vg_lookup on each VG after the vg_list and populating lvmcache with the info for each VG. These preliminary vg_lookup's are unnecessary, because they will be done again when the processing functions call vg_read. This patch eliminates the initial round of vg_lookup's, which can roughly cut in half the number of lvmetad requests and save a lot of extra work.
2015-05-06 00:24:50 +03:00
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
/*
* Needed for a current listing of the global VG namespace.
*/
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 (process_all_vgs_on_system && !lock_global(cmd, "sh")) {
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ECMD_FAILED;
goto_out;
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
scan: do scanning at the start of a command Move the location of scans to make it clearer and avoid unnecessary repeated scanning. There should be one scan at the start of a command which is then used through the rest of command processing. Previously, the initial label scan was called as a side effect from various utility functions. This would lead to it being called unnecessarily. It is an expensive operation, and should only be called when necessary. Also, this is a primary step in the function of the command, and as such it should be called prominently at the top level of command processing, not as a hidden side effect of a utility function. lvm knows exactly where and when the label scan needs to be done. Because of this, move the label scan calls from the internal functions to the top level of processing. Other specific instances of lvmcache_label_scan() are still called unnecessarily or unclearly by specific commands that do not use the common process_each functions. These will be improved in future commits. During the processing phase, rescanning labels for devices in a VG needs to be done after the VG lock is acquired in case things have changed since the initial label scan. This was being done by way of rescanning devices that had the INVALID flag set in lvmcache. This usually approximated the right set of devices, but it was not exact, and obfuscated the real requirement. Correct this by using a new function that rescans the devices in the VG: lvmcache_label_rescan_vg(). Apart from being inexact, the rescanning was extremely well hidden. _vg_read() would call ->create_instance(), _text_create_text_instance(), _create_vg_text_instance() which would call lvmcache_label_scan() which would call _scan_invalid() which repeats the label scan on devices flagged INVALID. lvmcache_label_rescan_vg() is now called prominently by _vg_read() directly.
2018-02-07 22:26:37 +03:00
/*
* Scan all devices to populate lvmcache with initial
* list of PVs and VGs.
*/
exit with error when --devicesfile name doesn't exist
2022-07-06 01:08:00 +03:00
if (!lvmcache_label_scan(cmd)) {
ret_max = ECMD_FAILED;
goto_out;
}
scan: do scanning at the start of a command Move the location of scans to make it clearer and avoid unnecessary repeated scanning. There should be one scan at the start of a command which is then used through the rest of command processing. Previously, the initial label scan was called as a side effect from various utility functions. This would lead to it being called unnecessarily. It is an expensive operation, and should only be called when necessary. Also, this is a primary step in the function of the command, and as such it should be called prominently at the top level of command processing, not as a hidden side effect of a utility function. lvm knows exactly where and when the label scan needs to be done. Because of this, move the label scan calls from the internal functions to the top level of processing. Other specific instances of lvmcache_label_scan() are still called unnecessarily or unclearly by specific commands that do not use the common process_each functions. These will be improved in future commits. During the processing phase, rescanning labels for devices in a VG needs to be done after the VG lock is acquired in case things have changed since the initial label scan. This was being done by way of rescanning devices that had the INVALID flag set in lvmcache. This usually approximated the right set of devices, but it was not exact, and obfuscated the real requirement. Correct this by using a new function that rescans the devices in the VG: lvmcache_label_rescan_vg(). Apart from being inexact, the rescanning was extremely well hidden. _vg_read() would call ->create_instance(), _text_create_text_instance(), _create_vg_text_instance() which would call lvmcache_label_scan() which would call _scan_invalid() which repeats the label scan on devices flagged INVALID. lvmcache_label_rescan_vg() is now called prominently by _vg_read() directly.
2018-02-07 22:26:37 +03:00
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
/*
* A list of all VGs on the system is needed when:
* . processing all VGs on the system
* . A VG name is specified which may refer to one
* of multiple VGs on the system with that name.
*/
log: Improve various device-related messages - Use 'lvmcache' consistently instead of 'metadata cache' - Always use 5 characters for source line number - Remember to convert uuids into printable form - Use <no name> rather than (null) when VG has no name.
2017-11-13 17:43:32 +03:00
log_very_verbose("Obtaining the complete list of VGs before processing their LVs");
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
lvmcache: remove wrapper around lvmcache_get_vgnameids This was left over from when there was an lvmetad version of the function.
2019-06-11 22:09:13 +03:00
if (!lvmcache_get_vgnameids(cmd, &vgnameids_on_system, NULL, 0)) {
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ECMD_FAILED;
goto_out;
Add lvmlockd
2015-03-05 23:00:44 +03:00
}
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
process_each: resolve duplicate VG names If two different VGs with the same name exist on the system, a command that just specifies that ambiguous name will fail with a new error: $ vgs -o name,uuid ... foo qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf foo vfhKCP-mpc7-KLLL-Uh08-4xPG-zLNR-4cnxJX $ lvs foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ vgremove foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ lvs -S vg_uuid=qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf lv1 foo ... This is implemented for process_each_vg/lv, and works with or without lvmetad. It does not work for commands that do not use process_each. This change includes one exception to the behavior shown above. If one of the VGs is foreign, and the other is not, then the command assumes that the intended VG is the local one and uses it.
2015-11-30 21:11:01 +03:00
if (!dm_list_empty(&arg_vgnames)) {
/* This may remove entries from arg_vgnames or vgnameids_on_system. */
ret = _resolve_duplicate_vgnames(cmd, &arg_vgnames, &vgnameids_on_system);
if (ret > ret_max)
ret_max = ret;
if (dm_list_empty(&arg_vgnames) && dm_list_empty(&arg_tags)) {
ret_max = ECMD_FAILED;
cleanup: update messages
2017-06-23 11:59:12 +03:00
goto_out;
process_each: resolve duplicate VG names If two different VGs with the same name exist on the system, a command that just specifies that ambiguous name will fail with a new error: $ vgs -o name,uuid ... foo qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf foo vfhKCP-mpc7-KLLL-Uh08-4xPG-zLNR-4cnxJX $ lvs foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ vgremove foo Multiple VGs found with the same name: foo Use the --select option with VG UUID (vg_uuid). $ lvs -S vg_uuid=qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf lv1 foo ... This is implemented for process_each_vg/lv, and works with or without lvmetad. It does not work for commands that do not use process_each. This change includes one exception to the behavior shown above. If one of the VGs is foreign, and the other is not, then the command assumes that the intended VG is the local one and uses it.
2015-11-30 21:11:01 +03:00
}
}
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
if (dm_list_empty(&arg_vgnames) && dm_list_empty(&vgnameids_on_system)) {
/* FIXME Should be log_print, but suppressed for reporting cmds */
debug: switch to verbose When there is no real error from the function - avoid using log_error().
2014-11-14 18:11:43 +03:00
log_verbose("No volume groups found.");
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
ret_max = ECMD_PROCESSED;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
goto out;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
}
vgs, lvs: ignore error if VG is removed If a VG is removed between the time that 'vgs' or 'lvs' (with no args) creates the list of VGs and the time that it reads the VG to process it, then ignore the removed VG; don't report an error that it could not be found, since it wasn't named by the command.
2015-10-27 18:52:01 +03:00
if (dm_list_empty(&arg_vgnames))
read_flags |= READ_OK_NOTFOUND;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
/*
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
* When processing all VGs, vgnameids_on_system simply becomes
* vgnameids_to_process.
* When processing only specified VGs, then for each item in
* arg_vgnames, move the corresponding entry from
* vgnameids_on_system to vgnameids_to_process.
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
*/
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
if (process_all_vgs_on_system)
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
dm_list_splice(&vgnameids_to_process, &vgnameids_on_system);
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
else
_choose_vgs_to_process(cmd, &arg_vgnames, &vgnameids_on_system, &vgnameids_to_process);
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
vgs, lvs: ignore error if VG is removed If a VG is removed between the time that 'vgs' or 'lvs' (with no args) creates the list of VGs and the time that it reads the VG to process it, then ignore the removed VG; don't report an error that it could not be found, since it wasn't named by the command.
2015-10-27 18:52:01 +03:00
ret = _process_lv_vgnameid_list(cmd, read_flags, &vgnameids_to_process, &arg_vgnames, &arg_lvnames,
process_each_lv: add check_single_lv function The new check_single_lv() function is called prior to the existing process_single_lv(). If the check function returns 0, the LV will not be processed. The check_single_lv function is meant to be a standard method to validate the combination of specific command + specific LV, and decide if the combination is allowed. The check_single function can be used by anything that calls process_each_lv. As commands are migrated to take advantage of command definitions, each command definition gets its own entry point which calls process_each for itself, passing a pair of check_single/process_single functions which can be specific to the narrowly defined command def.
2016-11-29 21:00:15 +03:00
&arg_tags, handle, check_single_lv, process_single_lv);
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
if (ret > ret_max)
ret_max = ret;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
out:
if (!handle_supplied)
cleanup: remove deallocate_handle_root arg from destroy_procesing_handle fnw
2015-02-13 12:42:21 +03:00
destroy_processing_handle(cmd, handle);
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_restore_report_state(saved_log_report_state);
process_each: always use list of vgnames on system This makes process_each_vg/lv always use the list of vgnames on the system. When specific VGs are named on the command line, the corresponding entries from vgnameids_on_system are moved to vgnameids_to_process. Previously, when specific VGs were named on the command line, the vgnameids_on_system list was not created, and vgnameids_to_process was created from the arg_vgnames list (which is only names, without vgids). Now, vgnameids_on_system is always created, and entries are moved from that list to vgnameids_to_process -- either some (when arg_vgnames specifies only some), or all (when the command is processing all VGs, or needs to look at all VGs for checking tags/selection). This change adds one new lvmetad lookup (vg_list) to a command that specifies VG names. It adds no new work for other commands, e.g. non-lvmetad commands, or commands that look at all VGs. When using lvmetad, 'lvs foo' previously sent one request to lvmetad: 'vg_lookup foo'. Now, 'lvs foo' sends two requests to lvmetad: 'vg_list' and 'vg_lookup foo <uuid>'. (The lookup can now always include the uuid in the request because the initial vg_list contains name/vgid pairs.)
2015-11-30 21:51:44 +03:00
return ret_max;
toollib: Rewrite process_each_lv. Copy the same form as the new process_each_vg. Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly. The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed. [Committed by agk with cosmetic changes and tweaks.]
2014-10-04 02:37:49 +04:00
}
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
static int _get_arg_pvnames(struct cmd_context *cmd,
int argc, char **argv,
struct dm_list *arg_pvnames,
struct dm_list *arg_tags)
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
{
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
int opt = 0;
char *at_sign, *tagname;
char *arg_name;
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
int ret_max = ECMD_PROCESSED;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
for (; opt < argc; opt++) {
arg_name = argv[opt];
dm_unescape_colons_and_at_signs(arg_name, NULL, &at_sign);
if (at_sign && (at_sign == arg_name)) {
tagname = at_sign + 1;
if (!validate_tag(tagname)) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("Skipping invalid tag %s.", tagname);
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
if (ret_max < EINVALID_CMD_LINE)
ret_max = EINVALID_CMD_LINE;
continue;
}
if (!str_list_add(cmd->mem, arg_tags,
dm_pool_strdup(cmd->mem, tagname))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("strlist allocation failed.");
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
return ECMD_FAILED;
}
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
continue;
}
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
if (!str_list_add(cmd->mem, arg_pvnames,
dm_pool_strdup(cmd->mem, arg_name))) {
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_error("strlist allocation failed.");
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
return ECMD_FAILED;
}
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
}
return ret_max;
}
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
static int _get_arg_devices(struct cmd_context *cmd,
struct dm_list *arg_pvnames,
struct dm_list *arg_devices)
{
struct dm_str_list *sl;
toollib: handle duplicate pvs in process_in_pv Processes a PV once for each time a device with its PV ID exists on the command line. This fixes a regression in the case where: . devices /dev/sdA and /dev/sdB where clones (same PV ID) . the cached VG references /dev/sdA . before the regression, the command: pvs /dev/sdB would display the cached device clone /dev/sdA . after the regression, pvs /dev/sdB would display nothing, causing vgimportclone /dev/sdB to fail. . with this fix, pvs /dev/sdB displays /dev/sdA Also, pvs /dev/sdA /dev/sdB will report two lines, one for each device on the command line, but /dev/sdA is displayed for each. This only works without lvmetad.
2015-01-09 23:55:16 +03:00
struct device_id_list *dil;
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
int ret_max = ECMD_PROCESSED;
dm_list_iterate_items(sl, arg_pvnames) {
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
if (!(dil = dm_pool_zalloc(cmd->mem, sizeof(*dil)))) {
toollib: handle duplicate pvs in process_in_pv Processes a PV once for each time a device with its PV ID exists on the command line. This fixes a regression in the case where: . devices /dev/sdA and /dev/sdB where clones (same PV ID) . the cached VG references /dev/sdA . before the regression, the command: pvs /dev/sdB would display the cached device clone /dev/sdA . after the regression, pvs /dev/sdB would display nothing, causing vgimportclone /dev/sdB to fail. . with this fix, pvs /dev/sdB displays /dev/sdA Also, pvs /dev/sdA /dev/sdB will report two lines, one for each device on the command line, but /dev/sdA is displayed for each. This only works without lvmetad.
2015-01-09 23:55:16 +03:00
log_error("device_id_list alloc failed.");
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
return ECMD_FAILED;
}
devices: initial use of existing option Use dev_cache_get_existing() in a few common, high level locations where it's obvious that only existing dev-cache entries are wanted. This can be expanded and used in more locations (or dev_cache_get can stop creating new entries.)
2022-02-25 01:10:37 +03:00
if (!(dil->dev = dev_cache_get_existing(cmd, sl->str, cmd->filter))) {
improve message for invalid device arg in process_each_pv Multiple commands process pvs by name using process_each_pv() and will now have an improved error message for a device that's excluded by filters.
2020-10-01 20:34:36 +03:00
log_error("Cannot use %s: %s", sl->str, devname_error_reason(sl->str));
toollib: use EINIT_FAILED for missing devs There is really no practical reason to continue running when we fail on allocation. It seems we may need further fine frained errors, as for some error type we simply need to exit ASAP, while others may still produce usable results.
2021-03-10 16:37:19 +03:00
ret_max = EINIT_FAILED;
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
} else {
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
memcpy(dil->pvid, dil->dev->pvid, ID_LEN);
toollib: handle duplicate pvs in process_in_pv Processes a PV once for each time a device with its PV ID exists on the command line. This fixes a regression in the case where: . devices /dev/sdA and /dev/sdB where clones (same PV ID) . the cached VG references /dev/sdA . before the regression, the command: pvs /dev/sdB would display the cached device clone /dev/sdA . after the regression, pvs /dev/sdB would display nothing, causing vgimportclone /dev/sdB to fail. . with this fix, pvs /dev/sdB displays /dev/sdA Also, pvs /dev/sdA /dev/sdB will report two lines, one for each device on the command line, but /dev/sdA is displayed for each. This only works without lvmetad.
2015-01-09 23:55:16 +03:00
dm_list_add(arg_devices, &dil->list);
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
}
}
return ret_max;
}
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
/* Process devices that are not PVs. */
static int _process_other_devices(struct cmd_context *cmd,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct processing_handle *handle,
process_single_pv_fn_t process_single_pv)
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
{
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
struct dev_iter *iter;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
struct physical_volume pv_dummy;
struct physical_volume *pv;
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
struct device *dev;
int failed = 0;
int ret;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
log_debug("Processing devices that are not PVs");
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
/*
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
* We want devices here that passed filters during
* label_scan but were found to not be PVs.
*
* No filtering used in iter, DEV_SCAN_FOUND_NOLABEL
* was set by label_scan which did filtering.
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
*/
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
if (!(iter = dev_iter_create(NULL, 0)))
return_0;
while ((dev = dev_iter_get(cmd, iter))) {
if (sigint_caught()) {
failed = 1;
break;
}
if (!(dev->flags & DEV_SCAN_FOUND_NOLABEL))
continue;
/*
* Pretend that each device is a PV with dummy values.
* FIXME Formalise this extension or find an alternative.
*/
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
memset(&pv_dummy, 0, sizeof(pv_dummy));
dm_list_init(&pv_dummy.tags);
dm_list_init(&pv_dummy.segments);
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
pv_dummy.dev = dev;
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
pv = &pv_dummy;
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
log_very_verbose("Processing device %s.", dev_name(dev));
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
ret = process_single_pv(cmd, NULL, pv, handle);
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
if (ret != ECMD_PROCESSED)
failed = 1;
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
}
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
dev_iter_destroy(iter);
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
return failed ? 0 : 1;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
}
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
static int _process_duplicate_pvs(struct cmd_context *cmd,
struct dm_list *arg_devices,
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
int process_other_devices,
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
struct processing_handle *handle,
process_single_pv_fn_t process_single_pv)
{
struct device_id_list *dil;
struct device_list *devl;
struct dm_list unused_duplicate_devs;
struct lvmcache_info *info;
pvs: use dummy structs in duplicate processing Use the same dummy struct approach from report.c when a pv needs to be processed without a real vg.
2017-07-12 18:51:54 +03:00
const char *vgname;
const char *vgid;
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
int failed = 0;
int ret;
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
pvs: use dummy structs in duplicate processing Use the same dummy struct approach from report.c when a pv needs to be processed without a real vg.
2017-07-12 18:51:54 +03:00
struct physical_volume dummy_pv = {
cov: avoid passed invalid dummy structure Altough this dummy structure should not be using pe_size anywhere, make analyzer happier and avoid PV structures with zero pe_size.
2021-04-22 13:32:35 +03:00
.pe_size = 1,
pvs: use dummy structs in duplicate processing Use the same dummy struct approach from report.c when a pv needs to be processed without a real vg.
2017-07-12 18:51:54 +03:00
.tags = DM_LIST_HEAD_INIT(dummy_pv.tags),
.segments= DM_LIST_HEAD_INIT(dummy_pv.segments),
};
struct format_instance dummy_fid = {
.metadata_areas_in_use = DM_LIST_HEAD_INIT(dummy_fid.metadata_areas_in_use),
.metadata_areas_ignored = DM_LIST_HEAD_INIT(dummy_fid.metadata_areas_ignored),
};
struct volume_group dummy_vg = {
cov: initilized more struct members For some hypothetical path, make these vars defined.
2021-09-10 00:07:40 +03:00
.cmd = cmd,
.vgmem = cmd->mem,
cov: happier with defined extent_size Set extent_size with != 0 value so there is not division by 0 in any code path.
2021-03-09 21:28:24 +03:00
.extent_size = 1,
pvs: use dummy structs in duplicate processing Use the same dummy struct approach from report.c when a pv needs to be processed without a real vg.
2017-07-12 18:51:54 +03:00
.fid = &dummy_fid,
.name = "",
.system_id = (char *) "",
.pvs = DM_LIST_HEAD_INIT(dummy_vg.pvs),
.lvs = DM_LIST_HEAD_INIT(dummy_vg.lvs),
.historical_lvs = DM_LIST_HEAD_INIT(dummy_vg.historical_lvs),
.tags = DM_LIST_HEAD_INIT(dummy_vg.tags),
};
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
dm_list_init(&unused_duplicate_devs);
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
if (!lvmcache_get_unused_duplicates(cmd, &unused_duplicate_devs))
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
return_0;
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
dm_list_iterate_items(devl, &unused_duplicate_devs) {
/* Duplicates are displayed if -a is used or the dev is named as an arg. */
devices: factor common list functions which were duplicated in various places
2022-11-07 20:38:46 +03:00
if ((dil = device_id_list_find_dev(arg_devices, devl->dev)))
device_id_list_remove(arg_devices, devl->dev);
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
if (!process_other_devices && !dil)
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
continue;
command struct: remove command name refs Change run time access to the command_name struct cmd->cname instead of indirectly through cmd->command->cname. This removes the two run time fields from struct command.
2017-01-14 00:08:51 +03:00
if (!(cmd->cname->flags & ENABLE_DUPLICATE_DEVS))
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
continue;
/*
* Use the cached VG from the preferred device for the PV,
* the vg is only used to display the VG name.
*
* This VG from lvmcache was not read from the duplicate
* dev being processed here, but from the preferred dev
* in lvmcache.
*
* When a duplicate PV is displayed, the reporting fields
* that come from the VG metadata are not shown, because
* the dev is not a part of the VG, the dev for the
* preferred PV is (also the VG metadata in lvmcache is
* not from the duplicate dev, but from the preferred dev).
*/
log_very_verbose("Processing duplicate device %s.", dev_name(devl->dev));
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
/*
* Don't pass dev to lvmcache_info_from_pvid because we looking
* for the chosen/preferred dev for this pvid.
*/
toollib: clean up coverity issue in processing duplicate pvs.
2016-10-05 00:25:32 +03:00
if (!(info = lvmcache_info_from_pvid(devl->dev->pvid, NULL, 0))) {
log_error(INTERNAL_ERROR "No info for pvid");
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
return 0;
toollib: clean up coverity issue in processing duplicate pvs.
2016-10-05 00:25:32 +03:00
}
vgname = lvmcache_vgname_from_info(info);
pvs: use dummy structs in duplicate processing Use the same dummy struct approach from report.c when a pv needs to be processed without a real vg.
2017-07-12 18:51:54 +03:00
vgid = vgname ? lvmcache_vgid_from_vgname(cmd, vgname) : NULL;
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
pvs: use dummy structs in duplicate processing Use the same dummy struct approach from report.c when a pv needs to be processed without a real vg.
2017-07-12 18:51:54 +03:00
dummy_pv.dev = devl->dev;
dummy_pv.fmt = lvmcache_fmt_from_info(info);
dummy_vg.name = vgname ?: "";
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
pvs: use dummy structs in duplicate processing Use the same dummy struct approach from report.c when a pv needs to be processed without a real vg.
2017-07-12 18:51:54 +03:00
if (vgid)
memcpy(&dummy_vg.id, vgid, ID_LEN);
else
memset(&dummy_vg.id, 0, sizeof(dummy_vg.id));
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
pvs: use dummy structs in duplicate processing Use the same dummy struct approach from report.c when a pv needs to be processed without a real vg.
2017-07-12 18:51:54 +03:00
ret = process_single_pv(cmd, &dummy_vg, &dummy_pv, handle);
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
if (ret != ECMD_PROCESSED)
failed = 1;
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
if (sigint_caught())
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
return_0;
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
}
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
return failed ? 0 : 1;
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
}
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
static int _process_pvs_in_vg(struct cmd_context *cmd,
struct volume_group *vg,
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
struct dm_list *arg_devices,
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
struct dm_list *arg_tags,
toollib: pvs -a should display VG name for each duplicate PV Previously, 'pvs -a' displayed the VG name for only the device associated with the cached PV (pv->dev), and other duplicate devices would have a blank VG name. This commit displays the VG name for each of the duplicate devices. The cost of doing this is not small: for each PV processed, the list of all devices must be searched for duplicates.
2015-01-14 23:16:03 +03:00
int process_all_pvs,
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
int skip,
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
uint32_t error_flags,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct processing_handle *handle,
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
process_single_pv_fn_t process_single_pv)
{
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_report_t saved_log_report_state = log_get_report_state();
char pv_uuid[64] __attribute__((aligned(8)));
char vg_uuid[64] __attribute__((aligned(8)));
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
int handle_supplied = handle != NULL;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
struct physical_volume *pv;
struct pv_list *pvl;
toollib: handle duplicate pvs in process_in_pv Processes a PV once for each time a device with its PV ID exists on the command line. This fixes a regression in the case where: . devices /dev/sdA and /dev/sdB where clones (same PV ID) . the cached VG references /dev/sdA . before the regression, the command: pvs /dev/sdB would display the cached device clone /dev/sdA . after the regression, pvs /dev/sdB would display nothing, causing vgimportclone /dev/sdB to fail. . with this fix, pvs /dev/sdB displays /dev/sdA Also, pvs /dev/sdA /dev/sdB will report two lines, one for each device on the command line, but /dev/sdA is displayed for each. This only works without lvmetad.
2015-01-09 23:55:16 +03:00
struct device_id_list *dil;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
const char *pv_name;
int process_pv;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
int do_report_ret_code = 1;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
int ret_max = ECMD_PROCESSED;
int ret = 0;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_PV);
vg_uuid[0] = '\0';
if (!id_write_format(&vg->id, vg_uuid, sizeof(vg_uuid)))
stack;
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 && (!(handle = init_processing_handle(cmd, NULL)))) {
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
ret_max = ECMD_FAILED;
goto_out;
}
if (handle->internal_report_for_select && !handle->selection_handle &&
select: initialize selection handle for process_each_* fns with initial report type This is a followup patch for previous patchset that enables selection in process_each_* fns to fix an issue where field prefixes are not automatically used for fields in selection criteria. Use initial report type that matches the intention of each process_each_* functions: - _process_pvs_in_vg - PVS - process_each_vg - VGS - process_each_lv and process_each_lv_in_vg - LVS This is not normally needed for the selection handle init, BUT we would miss the field prefix matching, e.g. lvchange -ay -S 'name=lvol0' The "name" above would not work if we didn't initialize reporting with the LVS type at its start. If we pass proper init type, reporting code can deduce the prefix automatically ("lv_name" in this case). This report type is then changed further based on what selection criteria we have. When doing pure selection, not report output, the final report type is purely based on combination of this initial report type and report types of the fields used in selection criteria.
2015-02-10 15:46:37 +03:00
!init_selection_handle(cmd, handle, PVS)) {
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
ret_max = ECMD_FAILED;
goto_out;
}
log: use separate 'orphan' report object type for orphan VGs
2016-06-14 14:21:53 +03:00
if (!is_orphan_vg(vg->name))
log_set_report_object_group_and_group_id(vg->name, vg_uuid);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
dm_list_iterate_items(pvl, &vg->pvs) {
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
pv = pvl->pv;
pv_name = pv_dev_name(pv);
pv_uuid[0]='\0';
if (!id_write_format(&pv->id, pv_uuid, sizeof(pv_uuid)))
stack;
log_set_report_object_name_and_id(pv_name, pv_uuid);
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
if (sigint_caught()) {
ret_max = ECMD_FAILED;
goto_out;
}
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
toollib: pvs -a should display VG name for each duplicate PV Previously, 'pvs -a' displayed the VG name for only the device associated with the cached PV (pv->dev), and other duplicate devices would have a blank VG name. This commit displays the VG name for each of the duplicate devices. The cost of doing this is not small: for each PV processed, the list of all devices must be searched for duplicates.
2015-01-14 23:16:03 +03:00
process_pv = process_all_pvs;
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
dil = NULL;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
/* Remove each arg_devices entry as it is processed. */
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
if (arg_devices && !dm_list_empty(arg_devices)) {
devices: factor common list functions which were duplicated in various places
2022-11-07 20:38:46 +03:00
if ((dil = device_id_list_find_dev(arg_devices, pv->dev)))
device_id_list_remove(arg_devices, dil->dev);
toollib: handle duplicate pvs in process_in_pv Processes a PV once for each time a device with its PV ID exists on the command line. This fixes a regression in the case where: . devices /dev/sdA and /dev/sdB where clones (same PV ID) . the cached VG references /dev/sdA . before the regression, the command: pvs /dev/sdB would display the cached device clone /dev/sdA . after the regression, pvs /dev/sdB would display nothing, causing vgimportclone /dev/sdB to fail. . with this fix, pvs /dev/sdB displays /dev/sdA Also, pvs /dev/sdA /dev/sdB will report two lines, one for each device on the command line, but /dev/sdA is displayed for each. This only works without lvmetad.
2015-01-09 23:55:16 +03:00
}
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
if (!process_pv && dil)
process_pv = 1;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
if (!process_pv && !dm_list_empty(arg_tags) &&
str_list_match_list(arg_tags, &pv->tags, NULL))
process_pv = 1;
toollib: simplify internal selection calls for non-reporting tools Some of the variables were set superfluously - we can just use existing "struct processing_handle" which includes "struct selection_handle".
2016-05-30 17:28:47 +03:00
process_pv = process_pv && select_match_pv(cmd, handle, vg, pv) && _select_matches(handle);
toollib: prepare select_match_{pv,vg,lv} hooks These hooks will check currently processed PV/VG/LV with current selection criteria and the processing continues only if there's a match.
2014-11-24 13:08:41 +03:00
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
/*
* The command has asked to process a specific PV
* named on the command line, but the VG containing
* that PV cannot be accessed. In this case report
* and return an error. If the inaccessible PV is
* not explicitly named on the command line, it is
* silently skipped.
*/
if (process_pv && skip && dil && error_flags) {
if (error_flags & FAILED_EXPORTED)
log_error("Cannot use PV %s in exported VG %s.", pv_name, vg->name);
if (error_flags & FAILED_SYSTEMID)
log_error("Cannot use PV %s in foreign VG %s.", pv_name, vg->name);
if (error_flags & (FAILED_LOCK_TYPE | FAILED_LOCK_MODE))
log_error("Cannot use PV %s in shared VG %s.", pv_name, vg->name);
ret_max = ECMD_FAILED;
}
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
if (process_pv) {
if (skip)
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_verbose("Skipping PV %s in VG %s.", pv_name, vg->name);
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
else
cleanup: add '.' to log messages
2014-11-14 18:08:27 +03:00
log_very_verbose("Processing PV %s in VG %s.", pv_name, vg->name);
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
if (!skip) {
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
ret = process_single_pv(cmd, vg, pv, handle);
if (ret != ECMD_PROCESSED)
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
stack;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret);
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
if (ret > ret_max)
ret_max = ret;
}
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
}
/*
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
* When processing only specific PVs, we can quit once they've all been found.
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
*/
cov: check for NULL Since we check for NULL pointers earlier we need to be consistent across function - since the NULL would applies across whole function. When dropping 'mda' check - we are actually already dereferencing it before - so it can't be NULL at that places (and it's validated before entering _read_mda_header_and_metadata).
2019-11-14 19:04:33 +03:00
if (!process_all_pvs && dm_list_empty(arg_tags) &&
(!arg_devices || dm_list_empty(arg_devices)))
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
break;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
}
process_each_pv handle outdated pvs process_each_pv should account for outdated pvs in the list of all devices it is processing.
2019-02-06 22:00:33 +03:00
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
do_report_ret_code = 0;
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
out:
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
if (do_report_ret_code)
report_log_ret_code(ret_max);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
log_set_report_object_group_and_group_id(NULL, NULL);
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns Call _init_processing_handle, _init_selection_handle and _destroy_processing_handle in process_each_* and related functions to set up and destroy handles used while processing items.
2014-11-28 17:04:25 +03:00
if (!handle_supplied)
cleanup: remove deallocate_handle_root arg from destroy_procesing_handle fnw
2015-02-13 12:42:21 +03:00
destroy_processing_handle(cmd, handle);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_restore_report_state(saved_log_report_state);
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
return ret_max;
}
/*
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
* Iterate through all PVs in each listed VG. Process a PV if
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
* its dev or tag matches arg_devices or arg_tags. If both
* arg_devices and arg_tags are empty, then process all PVs.
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
* No PV should be processed more than once.
*
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
* Each PV is removed from arg_devices when it is processed.
* Any names remaining in arg_devices were not found, and
* should produce an error.
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
*/
vg_read: sometimes ignore read errors Running "vgremove -f VG & pvs" results in the pvs command reporting that the VG is not found or is inconsistent. If the VG is gone or being removed, the pvs command should just skip it and not print errors about it. "Not found" is because the pvs command created the list of VGs to process, including VG, then vgremove removed the VG, then the pvs command came to to read the VG to process it and did not find it. An "inconsistent" error could be reported if vgremove had only partially completed removing VG when pvs did vg_read on the VG to process it, causing pvs to find the VG in a partially-removed state. This fix adds a flag that pvs uses to ignore a VG that can't be read or is inconsistent.
2015-10-22 22:56:22 +03:00
static int _process_pvs_in_vgs(struct cmd_context *cmd, uint32_t read_flags,
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
struct dm_list *all_vgnameids,
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
struct dm_list *arg_devices,
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
struct dm_list *arg_tags,
toollib: pvs -a should display VG name for each duplicate PV Previously, 'pvs -a' displayed the VG name for only the device associated with the cached PV (pv->dev), and other duplicate devices would have a blank VG name. This commit displays the VG name for each of the duplicate devices. The cost of doing this is not small: for each PV processed, the list of all devices must be searched for duplicates.
2015-01-14 23:16:03 +03:00
int process_all_pvs,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct processing_handle *handle,
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
process_single_pv_fn_t process_single_pv)
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
{
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_report_t saved_log_report_state = log_get_report_state();
char uuid[64] __attribute__((aligned(8)));
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
struct volume_group *vg;
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
struct volume_group *error_vg;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
struct vgnameid_list *vgnl;
const char *vg_name;
const char *vg_uuid;
coverity: fix missing initialization ... Using uninitialized value "lockd_state" when calling "lockd_vg" (even though lockd_vg assigns 0 to the lockd_state, but it looks at previous state of lockd_state just before that so we need to have that properly initialized!) libdm/libdm-report.c:2934: uninit_use_in_call: Using uninitialized value "tm". Field "tm.tm_gmtoff" is uninitialized when calling "_get_final_time". daemons/lvmlockd/lvmlockctl.c:273: uninit_use_in_call: Using uninitialized element of array "r_name" when calling "format_info_r_action". (just added FIXME as this looks unfinished?)
2015-07-08 15:53:23 +03:00
uint32_t lockd_state = 0;
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
uint32_t error_flags = 0;
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
int ret_max = ECMD_PROCESSED;
int ret;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
int skip;
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
int notfound;
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
int is_lockd;
coverity: fix issues detected in recent code Uninitialized variables (UNINIT) /safe/guest2/covscan/LVM2.2.02.158/tools/toollib.c: 3520 in _process_pvs_in_vgs() Uninitialized variables (UNINIT) Using uninitialized value "do_report_ret_code". Null pointer dereferences (REVERSE_INULL) /safe/guest2/covscan/LVM2.2.02.158/libdm/libdm-report.c: 4745 in dm_report_output() Null pointer dereferences (REVERSE_INULL) Null-checking "rh" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. Incorrect expression (MISSING_COMMA) /safe/guest2/covscan/LVM2.2.02.158/lib/log/log.c: 280 in _get_log_level_name() Incorrect expression (MISSING_COMMA) In the initialization of "log_level_names", a suspicious concatenated string ""noticeinfo"" is produced. Null pointer dereferences (FORWARD_NULL) /safe/guest2/covscan/LVM2.2.02.158/tools/reporter.c: 816 in_get_report_options() Null pointer dereferences (FORWARD_NULL) Comparing "mem" to null implies that "mem" might be null.
2016-06-27 11:12:41 +03:00
int do_report_ret_code = 1;
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_VG);
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
dm_list_iterate_items(vgnl, all_vgnameids) {
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
vg_name = vgnl->vg_name;
vg_uuid = vgnl->vgid;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
skip = 0;
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
notfound = 0;
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
is_lockd = lvmcache_vg_is_lockd_type(cmd, vg_name, vg_uuid);
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
uuid[0] = '\0';
log: use separate 'orphan' report object type for orphan VGs
2016-06-14 14:21:53 +03:00
if (is_orphan_vg(vg_name)) {
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_ORPHAN);
log_set_report_object_name_and_id(vg_name + sizeof(VG_ORPHANS), uuid);
} else {
if (vg_uuid && !id_write_format((const struct id*)vg_uuid, uuid, sizeof(uuid)))
stack;
log_set_report_object_name_and_id(vg_name, uuid);
}
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
if (sigint_caught()) {
ret_max = ECMD_FAILED;
goto_out;
}
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
do_lockd:
if (is_lockd && !lockd_vg(cmd, vg_name, NULL, 0, &lockd_state)) {
Add lvmlockd
2015-03-05 23:00:44 +03:00
ret_max = ECMD_FAILED;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret_max);
Add lvmlockd
2015-03-05 23:00:44 +03:00
continue;
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
log_debug("Processing PVs in VG %s", vg_name);
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
error_flags = 0;
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
vg = vg_read(cmd, vg_name, vg_uuid, read_flags, lockd_state, &error_flags, &error_vg);
cov: ensure there is either vg or error_vg Make it explicitely visible to coverity that _process_pvs_in_vg() is not passing NULL vg.
2023-04-26 14:38:22 +03:00
if (_ignore_vg(cmd, error_flags, error_vg, vg_name, NULL, read_flags, &skip, &notfound) ||
(!vg && !error_vg)) {
toolib: fix ignore_vg Rework ignore_vg() API so it properly handles multiple kind of vg_read_error() states. Skip processing only otherwise valid VG. Always return ECMD_FAILED when break is detected. Check sigint_caught() in front of dm iterator loop. Add stack for _process failing ret codes.
2014-11-14 12:50:31 +03:00
stack;
toollib: improve ignore_vg case in _process_pvs_in_vgs ignore_vg now returns 0 for the FAILED_CLUSTERED case, so all the ignore_vg 1 cases will return vg's with an empty vg->pvs, so we do not need to iterate through vg->pvs to remove the entries from the devices list. Clean up whitespace problems in that area from the previous commit.
2014-11-18 18:22:37 +03:00
ret_max = ECMD_FAILED;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret_max);
toolib: skip when there is no vg and error_vg We must skip even if the skip would be suggesting otherwise if there is no vg and no error_vg as there is nothing to process.
2024-04-09 18:27:12 +03:00
if (!skip || (!vg && !error_vg))
Add lvmlockd
2015-03-05 23:00:44 +03:00
goto endvg;
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
/* Drop through to eliminate unmpermitted PVs from the devices list */
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
}
pvs: fix missing PVs when VG is removed PVs could be missing from the 'pvs' output if their VG was removed at the same time that the 'pvs' command was run. To fix this: 1. If a VG is not found when processed, don't silently skip the PVs in it, as is done when the "skip" variable is set. 2. Repeat the VG search if some PVs are not found on the first search through all VGs. The second search uses a specific list of PVs that were missed the first time. testing: /dev/sdb is a PV /dev/sdd is a PV /dev/sdg is not a PV each test begins with: vgcreate test /dev/sdb /dev/sdd variations to test: vgremove -f test & pvs vgremove -f test & pvs -a vgremove -f test & pvs /dev/sdb /dev/sdd vgremove -f test & pvs /dev/sdg vgremove -f test & pvs /dev/sdb /dev/sdg The pvs command should always display /dev/sdb and /dev/sdd, either as a part of VG test or not. The pvs command should always print an error indicating that /dev/sdg could not be found.
2015-10-23 23:09:20 +03:00
if (notfound)
goto endvg;
cov: ensure there is either vg or error_vg Make it explicitely visible to coverity that _process_pvs_in_vg() is not passing NULL vg.
2023-04-26 14:38:22 +03:00
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
if (vg && !is_lockd && vg_is_shared(vg)) {
/* The lock_type changed since label_scan, won't really occur in practice. */
log_debug("Repeat lock and read for local to shared vg");
unlock_and_release_vg(cmd, vg, vg_name);
is_lockd = 1;
goto do_lockd;
}
toollib: improve ignore_vg case in _process_pvs_in_vgs ignore_vg now returns 0 for the FAILED_CLUSTERED case, so all the ignore_vg 1 cases will return vg's with an empty vg->pvs, so we do not need to iterate through vg->pvs to remove the entries from the devices list. Clean up whitespace problems in that area from the previous commit.
2014-11-18 18:22:37 +03:00
/*
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
* Don't call "continue" when skip is set, because we need to remove
* error_vg->pvs entries from devices list.
toollib: improve ignore_vg case in _process_pvs_in_vgs ignore_vg now returns 0 for the FAILED_CLUSTERED case, so all the ignore_vg 1 cases will return vg's with an empty vg->pvs, so we do not need to iterate through vg->pvs to remove the entries from the devices list. Clean up whitespace problems in that area from the previous commit.
2014-11-18 18:22:37 +03:00
*/
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
ret = _process_pvs_in_vg(cmd, vg ? vg : error_vg, arg_devices, arg_tags,
process_all_pvs, skip, error_flags,
toollib: pvs -a should display VG name for each duplicate PV Previously, 'pvs -a' displayed the VG name for only the device associated with the cached PV (pv->dev), and other duplicate devices would have a blank VG name. This commit displays the VG name for each of the duplicate devices. The cost of doing this is not small: for each PV processed, the list of all devices must be searched for duplicates.
2015-01-14 23:16:03 +03:00
handle, process_single_pv);
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (ret != ECMD_PROCESSED)
stack;
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret);
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
toollib: improve ignore_vg case in _process_pvs_in_vgs ignore_vg now returns 0 for the FAILED_CLUSTERED case, so all the ignore_vg 1 cases will return vg's with an empty vg->pvs, so we do not need to iterate through vg->pvs to remove the entries from the devices list. Clean up whitespace problems in that area from the previous commit.
2014-11-18 18:22:37 +03:00
if (ret > ret_max)
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
ret_max = ret;
clang: add explicit test for VG Clang can't figure out connection to 'skip' variable.
2021-09-19 00:16:30 +03:00
if (!skip && vg)
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, vg->name);
Add lvmlockd
2015-03-05 23:00:44 +03:00
endvg:
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
if (error_vg)
unlock_and_release_vg(cmd, error_vg, vg_name);
Add lvmlockd
2015-03-05 23:00:44 +03:00
release_vg(vg);
lvmlockd: avoid lockd_vg for local VGs Previously, a command would call lockd_vg() for a local VG, which would go to lvmlockd, which would send back ENOLS, and the command would not care when it saw the VG was local. The pointless back-and-forth to lvmlockd for local VGs can be avoided by checking the VG lock_type in lvmcache (which label_scan now saves there; this wasn't the case back when the original lockd_vg logic was added.) If the lock_type saved during label_scan indicates a local VG, then the lockd_vg step is skipped.
2024-06-12 23:36:45 +03:00
if (is_lockd && !lockd_vg(cmd, vg_name, "un", 0, &lockd_state))
lockd: check for failing unlock Avoid ignoring unlocking error.
2015-08-18 12:46:42 +03:00
stack;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
/* Quit early when possible. */
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
if (!process_all_pvs && dm_list_empty(arg_tags) && dm_list_empty(arg_devices)) {
do_report_ret_code = 0;
cleanup: remove stack tracing for ok path
2017-11-10 15:41:45 +03:00
goto out;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
}
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
}
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
do_report_ret_code = 0;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
out:
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
if (do_report_ret_code)
report_log_ret_code(ret_max);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_restore_report_state(saved_log_report_state);
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
return ret_max;
}
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
int process_each_pv(struct cmd_context *cmd,
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
int argc, char **argv, const char *only_this_vgname,
int all_is_set, uint32_t read_flags,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct processing_handle *handle,
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
process_single_pv_fn_t process_single_pv)
{
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_report_t saved_log_report_state = log_get_report_state();
vgreduce: Use process_each_pv. Adapt process_each_pv for use by vgreduce in the non-repair case. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:53:56 +04:00
struct dm_list arg_tags; /* str_list */
struct dm_list arg_pvnames; /* str_list */
toollib: handle duplicate pvs in process_in_pv Processes a PV once for each time a device with its PV ID exists on the command line. This fixes a regression in the case where: . devices /dev/sdA and /dev/sdB where clones (same PV ID) . the cached VG references /dev/sdA . before the regression, the command: pvs /dev/sdB would display the cached device clone /dev/sdA . after the regression, pvs /dev/sdB would display nothing, causing vgimportclone /dev/sdB to fail. . with this fix, pvs /dev/sdB displays /dev/sdA Also, pvs /dev/sdA /dev/sdB will report two lines, one for each device on the command line, but /dev/sdA is displayed for each. This only works without lvmetad.
2015-01-09 23:55:16 +03:00
struct dm_list arg_devices; /* device_id_list */
vgreduce: Use process_each_pv. Adapt process_each_pv for use by vgreduce in the non-repair case. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:53:56 +04:00
struct dm_list all_vgnameids; /* vgnameid_list */
toollib: handle duplicate pvs in process_in_pv Processes a PV once for each time a device with its PV ID exists on the command line. This fixes a regression in the case where: . devices /dev/sdA and /dev/sdB where clones (same PV ID) . the cached VG references /dev/sdA . before the regression, the command: pvs /dev/sdB would display the cached device clone /dev/sdA . after the regression, pvs /dev/sdB would display nothing, causing vgimportclone /dev/sdB to fail. . with this fix, pvs /dev/sdB displays /dev/sdA Also, pvs /dev/sdA /dev/sdB will report two lines, one for each device on the command line, but /dev/sdA is displayed for each. This only works without lvmetad.
2015-01-09 23:55:16 +03:00
struct device_id_list *dil;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
int process_all_pvs;
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
int process_other_devices;
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
int ret_max = ECMD_PROCESSED;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
int ret;
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_PV);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
log_debug("Processing each PV");
vg_read: sometimes ignore read errors Running "vgremove -f VG & pvs" results in the pvs command reporting that the VG is not found or is inconsistent. If the VG is gone or being removed, the pvs command should just skip it and not print errors about it. "Not found" is because the pvs command created the list of VGs to process, including VG, then vgremove removed the VG, then the pvs command came to to read the VG to process it and did not find it. An "inconsistent" error could be reported if vgremove had only partially completed removing VG when pvs did vg_read on the VG to process it, causing pvs to find the VG in a partially-removed state. This fix adds a flag that pvs uses to ignore a VG that can't be read or is inconsistent.
2015-10-22 22:56:22 +03:00
/*
* When processing a specific VG name, warn if it's inconsistent and
* print an error if it's not found. Otherwise we're processing all
* VGs, in which case the command doesn't care if the VG is inconsisent
* or not found; it just wants to skip that VG. (It may be not found
* if it was removed between creating the list of all VGs and then
* processing each VG.
*/
if (only_this_vgname)
read_flags |= READ_WARN_INCONSISTENT;
else
read_flags |= READ_OK_NOTFOUND;
Add lvmlockd
2015-03-05 23:00:44 +03:00
/* Disable error in vg_read so we can print it from ignore_vg. */
cmd->vg_read_print_access_error = 0;
system_id: remove unwanted foreign error for some commands Commands that can never use foreign VGs begin with cmd->error_foreign_vgs = 1. This tells the vg_read lib layer to print an error as soon as a foreign VG is read. The toollib process_each layer also prints an error if a foreign VG is read, but is more selective about it. It won't print an error if the command did not explicitly name the foreign VG. We want to silently ignore foreign VGs unless a command attempts to use one explicitly. So, foreign VG errors are printed from two different layers: vg_read (lower layer) and process_each (upper layer). Commands that use toollib process_each, only want errors from the process_each layer, not from both layers. So, process_each disables the lower layer vg_read error message by setting error_foreign_vgs = 0. Commands that do not use toollib process_each, want errors from the vg_read layer, otherwise they would get no error message. The original cmd->error_foreign_vgs setting enables this error. (Commands that are allowed to operate on foreign VGs always begin with cmd->error_foreign_vgs = 0, and all the commands in this group use toollib process_each with the selective error reporting.)
2015-02-27 01:06:32 +03:00
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
dm_list_init(&arg_tags);
dm_list_init(&arg_pvnames);
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
dm_list_init(&arg_devices);
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
dm_list_init(&all_vgnameids);
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
/*
* Create two lists from argv:
* arg_pvnames: pvs explicitly named in argv
* arg_tags: tags explicitly named in argv
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
*
* Then convert arg_pvnames, which are free-form, user-specified,
* names/paths into arg_devices which can be used to match below.
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
*/
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
if ((ret = _get_arg_pvnames(cmd, argc, argv, &arg_pvnames, &arg_tags)) != ECMD_PROCESSED) {
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
ret_max = ret;
goto_out;
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
}
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
command struct: remove command name refs Change run time access to the command_name struct cmd->cname instead of indirectly through cmd->command->cname. This removes the two run time fields from struct command.
2017-01-14 00:08:51 +03:00
if ((cmd->cname->flags & DISALLOW_TAG_ARGS) && !dm_list_empty(&arg_tags)) {
pvmove: disallow tag args pvmove began processing tags unintentionally from commit, 6d7dc87cb pvmove: use toollib pvmove works on a single PV, but tags can match multiple PVs. If we allowed tags, but processed only the first matching PV, then the resulting PV would be unpredictable. Also, the current processing code does not allow us to simply report an error and do nothing if more than one PV matches the tag, because the command starts processing PVs as they are found, so it's too late to do nothing if a second PV matches.
2016-06-03 17:56:48 +03:00
log_error("Tags cannot be used with this command.");
return ECMD_FAILED;
}
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
process_all_pvs = dm_list_empty(&arg_pvnames) && dm_list_empty(&arg_tags);
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
process_other_devices = process_all_pvs && (cmd->cname->flags & ENABLE_ALL_DEVS) && all_is_set;
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
Add lvmlockd
2015-03-05 23:00:44 +03:00
/* Needed for a current listing of the global VG namespace. */
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 (!only_this_vgname && !lock_global(cmd, "sh")) {
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
ret_max = ECMD_FAILED;
goto_out;
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
exit with error when --devicesfile name doesn't exist
2022-07-06 01:08:00 +03:00
if (!(read_flags & PROCESS_SKIP_SCAN)) {
if (!lvmcache_label_scan(cmd)) {
ret_max = ECMD_FAILED;
goto_out;
}
}
process_each_pv: do full scan earlier to find new devices Before commit c1f246fedfc349c25749da501e68a7f70bd122b0, _get_all_devices() did a full device scan before get_vgnameids() was called. The full scan in _get_all_devices() is from calling dev_iter_create(f, 1). The '1' arg forces a full scan. By doing a full scan in _get_all_devices(), new devices were added to dev-cache before get_vgnameids() began scanning labels. So, labels would be read from new devices. (e.g. by the first 'pvs' command after the new device appeared.) After that commit, _get_all_devices() was called after get_vgnameids() was finished scanning labels. So, new devices would be missed while scanning labels. When _get_all_devices() saw the new devices (after labels were scanned), those devices were added to the .cache file. This meant that the second 'pvs' command would see the devices because they would be in .cache. Now, the full device scan is factored out of _get_all_devices() and called by itself at the start of the command so that new devices will be known before get_vgnameids() scans labels.
2015-12-11 23:02:36 +03:00
lvmcache: remove wrapper around lvmcache_get_vgnameids This was left over from when there was an lvmetad version of the function.
2019-06-11 22:09:13 +03:00
if (!lvmcache_get_vgnameids(cmd, &all_vgnameids, only_this_vgname, 1)) {
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
ret_max = ret;
goto_out;
toollib: fix duplicate handling in process_each_pv With use_lvmetad=0, duplicate PVs /dev/loop0 and /dev/loop1, where in this example, /dev/loop1 is the cached device referenced by pv->dev, the command 'pvs /dev/loop0' reports: Failed to find physical volume "/dev/loop0". This is because the duplicate PV detection by pvid is not working because _get_all_devices() is not setting any dev->pvid for any entries. This is because the pvid information has not yet been saved in lvmcache. This is fixed by calling _get_vgnameids_on_system() before _get_all_devices(), which has the effect of caching the necessary pvid information. With this fix, running pvs /dev/loop0, or pvs /dev/loop1, produces no error and one line of output for the PV (the device printed is the one cached in pv->dev, in this example /dev/loop1.) Running 'pvs /dev/loop0 /dev/loop1' produces no error and two lines of output, with each device displayed on one of the lines. Running 'pvs -a' shows two PVs, one with loop0 and one with loop1, and both shown as a member of the same VG. Running 'pvs' shows only one of the duplicate PVs, and that shows the device cached in pv->dev (loop1). The above output is what the duplicate handling code was previously designed to output in commits: b64da4d8b521 toollib: search for duplicate PVs only when needed 3a7c47af0e88 toollib: pvs -a should display VG name for each duplicate PV 57d74a45a05e toollib: override the PV device with duplicates c1f246fedfc3 toollib: handle duplicate pvs in process_in_pv As a further step after this, we may choose to change some of those. For all of these commands, a warning is printed about the existence of the duplicate PVs: Found duplicate PV ...: using /dev/loop1 not /dev/loop0
2015-04-20 22:35:35 +03:00
}
toollib: use EINIT_FAILED for missing devs There is really no practical reason to continue running when we fail on allocation. It seems we may need further fine frained errors, as for some error type we simply need to exit ASAP, while others may still produce usable results.
2021-03-10 16:37:19 +03:00
if ((ret = _get_arg_devices(cmd, &arg_pvnames, &arg_devices)) != ECMD_PROCESSED) {
/* get_arg_devices reports EINIT_FAILED for any PV names not found. */
ret_max = ret;
if (ret_max == ECMD_FAILED)
goto_out;
toollib: preserve return code 5
2021-03-11 02:54:32 +03:00
ret_max = ECMD_FAILED; /* but ATM we've returned FAILED for all cases */
toollib: use EINIT_FAILED for missing devs There is really no practical reason to continue running when we fail on allocation. It seems we may need further fine frained errors, as for some error type we simply need to exit ASAP, while others may still produce usable results.
2021-03-10 16:37:19 +03:00
}
toollib: Reorder process_each_pv initialisation. Perform cheaper command line-based validation before more-expensive processing and scanning.
2015-03-19 02:34:46 +03:00
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
ret = _process_pvs_in_vgs(cmd, read_flags, &all_vgnameids,
&arg_devices, &arg_tags, process_all_pvs,
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
handle, process_single_pv);
if (ret != ECMD_PROCESSED)
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
stack;
if (ret > ret_max)
ret_max = ret;
/*
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
* Process the list of unused duplicate devs to display duplicate PVs
* in two cases: 1. pvs -a (which has traditionally included duplicate
* PVs in addition to the expected non-PV devices), 2. pvs <devname>
* (duplicate dev is named on the command line.)
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
*/
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
if (process_other_devices || !dm_list_empty(&arg_devices)) {
if (!_process_duplicate_pvs(cmd, &arg_devices, process_other_devices, handle, process_single_pv))
ret_max = ECMD_FAILED;
}
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
toollib: handle duplicate pvs in process_in_pv Processes a PV once for each time a device with its PV ID exists on the command line. This fixes a regression in the case where: . devices /dev/sdA and /dev/sdB where clones (same PV ID) . the cached VG references /dev/sdA . before the regression, the command: pvs /dev/sdB would display the cached device clone /dev/sdA . after the regression, pvs /dev/sdB would display nothing, causing vgimportclone /dev/sdB to fail. . with this fix, pvs /dev/sdB displays /dev/sdA Also, pvs /dev/sdA /dev/sdB will report two lines, one for each device on the command line, but /dev/sdA is displayed for each. This only works without lvmetad.
2015-01-09 23:55:16 +03:00
dm_list_iterate_items(dil, &arg_devices) {
log_error("Failed to find physical volume \"%s\".", dev_name(dil->dev));
toollib: process_each_pv should match by device When processing PVs specified on the command line, the arg name was being matched against pv_dev_name, which will not always work: - The PV specified on the command line could be an alias, e.g. /dev/disk/by-id/... - The PV specified on the command line could be any random path to the device, e.g. /dev/../dev/sdb To fix this, first resolve the named PV args to struct device's, then iterate through the devices for processing.
2015-01-07 23:04:12 +03:00
ret_max = ECMD_FAILED;
}
toollib: remove all devices list from process_each_pv Reporting non-PVs / "all devices" is only done by pvs -a or pvdisplay -a, so avoid the work managing a list of all devices in process_each_pv. In the case when it's needed, use the results of label_scan which already determines which devs are not PVs.
2021-10-13 22:13:54 +03:00
/*
* pvs -a and pvdisplay -a want to show devices that are not PVs.
*/
if (process_other_devices) {
if (!_process_other_devices(cmd, handle, process_single_pv))
ret_max = ECMD_FAILED;
}
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
out:
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_restore_report_state(saved_log_report_state);
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
return ret_max;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
}
int process_each_pv_in_vg(struct cmd_context *cmd, struct volume_group *vg,
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
2014-11-27 17:02:13 +03:00
struct processing_handle *handle,
process_single_pv_fn_t process_single_pv)
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
{
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_report_t saved_log_report_state = log_get_report_state();
char pv_uuid[64] __attribute__((aligned(8)));
char vg_uuid[64] __attribute__((aligned(8)));
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
int whole_selected = 0;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
int ret_max = ECMD_PROCESSED;
int ret;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
int do_report_ret_code = 1;
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
struct pv_list *pvl;
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_type(LOG_REPORT_OBJECT_TYPE_PV);
vg_uuid[0] = '\0';
if (!id_write_format(&vg->id, vg_uuid, sizeof(vg_uuid)))
stack;
log: use separate 'orphan' report object type for orphan VGs
2016-06-14 14:21:53 +03:00
if (!is_orphan_vg(vg->name))
log_set_report_object_group_and_group_id(vg->name, vg_uuid);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
dm_list_iterate_items(pvl, &vg->pvs) {
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
pv_uuid[0] = '\0';
if (!id_write_format(&pvl->pv->id, pv_uuid, sizeof(pv_uuid)))
stack;
log_set_report_object_name_and_id(pv_dev_name(pvl->pv), pv_uuid);
if (sigint_caught()) {
ret_max = ECMD_FAILED;
goto_out;
}
toollib: ignore_vg() with skip is not locked Extend/fix d8923457b82456ebee3e333b3fcc26087483cd01 commit. 'skip'-ed VG is not holding any lock - so don't unlock such VG. At the same time simplify the code around and relase VG at a single place and unlock only not skiped and not ignored VGs.
2014-11-14 21:32:03 +03:00
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
ret = process_single_pv(cmd, vg, pvl->pv, handle);
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
_update_selection_result(handle, &whole_selected);
toollib: fixes and cleanup of recent changes - Fix problems with recent changes related to skipping in: . _process_vgnameid_list . _process_pvs_in_vgs - Undo unnecessary changes to the code structure and readability. - Preserve valid but minor changes: . testing FAILED bit values in ignore_vg . using "skip" value from ignore_vg instead of "ret" value . applying the sigint check to the start of all loops . setting stack backtrace when ECMD_PROCESSED is not returned, i.e. apply the following pattern: ret = process_foo(); if (ret != ECMD_PROCESSED) stack; if (ret > ret_max) ret_max = ret;
2014-11-15 00:00:35 +03:00
if (ret != ECMD_PROCESSED)
stack;
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
report_log_ret_code(ret);
toollib: ignore_vg() with skip is not locked Extend/fix d8923457b82456ebee3e333b3fcc26087483cd01 commit. 'skip'-ed VG is not holding any lock - so don't unlock such VG. At the same time simplify the code around and relase VG at a single place and unlock only not skiped and not ignored VGs.
2014-11-14 21:32:03 +03:00
if (ret > ret_max)
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
ret_max = ret;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_set_report_object_name_and_id(NULL, NULL);
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
}
toollib: select the whole structure if at least one of its items is selected This applies to: - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected So this patch causes the selection result to be properly propagated up to callers.
2014-12-03 16:20:00 +03:00
_set_final_selection_result(handle, whole_selected);
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
do_report_ret_code = 0;
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
out:
log: annotate processing code with report_current_object_cmdlog
2016-05-23 16:27:09 +03:00
if (do_report_ret_code)
report_log_ret_code(ret_max);
log: annotate processing code with log_set_report_{context,object_type,id_and_name}
2016-05-20 14:26:02 +03:00
log_restore_report_state(saved_log_report_state);
toollib: Rewrite process_each_pv. Process PVs by iterating through VGs, then iterating through devices if the command needs to process non-PV devices. The process_single function can always use the VG and PV args. [Committed by agk with cosmetic changes and tweaks.]
2014-10-07 03:34:04 +04:00
return ret_max;
toollib: Shuffle PV functions.
2014-10-07 01:02:00 +04:00
}
vgremove: Use process_each_lv_in_vg.
2014-10-07 19:45:45 +04:00
int lvremove_single(struct cmd_context *cmd, struct logical_volume *lv,
lvremove: remove device_id for PVs on LVs When PVs are created on LVs, remove the devices file entries for the PVs when the LVs are removed. In general, the devices file entries should be removed with lvmdevices --deldev when the LVs are removed (lvremove is the equivalent of detaching a device from the system when layering PVs on LVs.) This change is effectively an automatic lvmdevices --deldev command that is built into lvremove when the LV has a PV on it.
2024-05-22 23:32:17 +03:00
struct processing_handle *handle)
vgremove: Use process_each_lv_in_vg.
2014-10-07 19:45:45 +04:00
{
lvremove: check for handle Get lvremove_params from non NULL handle. Introduced in commit 47f8bda05. TODO: any more thing needed ?
2024-05-27 18:01:25 +03:00
struct lvremove_params *lp = (handle) ? (struct lvremove_params *) handle->custom_handle : NULL;
lvremove: remove device_id for PVs on LVs When PVs are created on LVs, remove the devices file entries for the PVs when the LVs are removed. In general, the devices file entries should be removed with lvmdevices --deldev when the LVs are removed (lvremove is the equivalent of detaching a device from the system when layering PVs on LVs.) This change is effectively an automatic lvmdevices --deldev command that is built into lvremove when the LV has a PV on it.
2024-05-22 23:32:17 +03:00
vgremove: Use process_each_lv_in_vg.
2014-10-07 19:45:45 +04:00
/*
* Single force is equivalent to single --yes
* Even multiple --yes are equivalent to single --force
* When we require -ff it cannot be replaced with -f -y
*/
force_t force = (force_t) arg_count(cmd, force_ARG)
? : (arg_is_set(cmd, yes_ARG) ? DONT_PROMPT : PROMPT);
if (!lv_remove_with_dependencies(cmd, lv, force, 0))
return_ECMD_FAILED;
lvremove: reuse existing dm_build_dm_uuid Use existing dm_build_dm_uuid() to generate LV's DM UUID.
2024-05-30 15:17:33 +03:00
if (cmd->scan_lvs && cmd->enable_devices_file && lp)
/* save for removal */
if (!str_list_add(cmd->mem, &lp->removed_uuids,
dm_build_dm_uuid(cmd->mem, UUID_PREFIX, lv->lvid.s, NULL)))
stack;
lvremove: remove device_id for PVs on LVs When PVs are created on LVs, remove the devices file entries for the PVs when the LVs are removed. In general, the devices file entries should be removed with lvmdevices --deldev when the LVs are removed (lvremove is the equivalent of detaching a device from the system when layering PVs on LVs.) This change is effectively an automatic lvmdevices --deldev command that is built into lvremove when the LV has a PV on it.
2024-05-22 23:32:17 +03:00
vgremove: Use process_each_lv_in_vg.
2014-10-07 19:45:45 +04:00
return ECMD_PROCESSED;
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
replace pvcreate_params with pvcreate_each_params "pvcreate_each_params" was a temporary name used to transition from the old "pvcreate_params". Remove the old pvcreate_params struct and rename the new pvcreate_each_params struct to pvcreate_params. Rename various pvcreate_each_params terms to simply pvcreate_params.
2016-02-19 00:38:23 +03:00
int pvcreate_params_from_args(struct cmd_context *cmd, struct pvcreate_params *pp)
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
{
pp->yes = arg_count(cmd, yes_ARG);
pp->force = (force_t) arg_count(cmd, force_ARG);
if (arg_int_value(cmd, labelsector_ARG, 0) >= LABEL_SCAN_SECTORS) {
log_error("labelsector must be less than %lu.",
LABEL_SCAN_SECTORS);
return 0;
}
tidy: prefer not using else after return clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
2017-07-19 17:16:12 +03:00
pp->pva.label_sector = arg_int64_value(cmd, labelsector_ARG,
DEFAULT_LABELSECTOR);
tools: Use arg_is_set instead of arg_count.
2016-06-22 00:24:52 +03:00
if (arg_is_set(cmd, metadataignore_ARG))
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
pp->pva.metadataignore = arg_int_value(cmd, metadataignore_ARG,
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
DEFAULT_PVMETADATAIGNORE);
else
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
pp->pva.metadataignore = find_config_tree_bool(cmd, metadata_pvmetadataignore_CFG, NULL);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
tools: Use arg_is_set instead of arg_count.
2016-06-22 00:24:52 +03:00
if (arg_is_set(cmd, pvmetadatacopies_ARG) &&
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
!arg_int_value(cmd, pvmetadatacopies_ARG, -1) &&
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
pp->pva.metadataignore) {
cleanup: update messages
2017-06-23 11:59:12 +03:00
log_error("metadataignore only applies to metadatacopies > 0.");
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
return 0;
}
pp->zero = arg_int_value(cmd, zero_ARG, 1);
if (arg_sign_value(cmd, dataalignment_ARG, SIGN_NONE) == SIGN_MINUS) {
log_error("Physical volume data alignment may not be negative.");
return 0;
}
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
pp->pva.data_alignment = arg_uint64_value(cmd, dataalignment_ARG, UINT64_C(0));
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
if (pp->pva.data_alignment > UINT32_MAX) {
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
log_error("Physical volume data alignment is too big.");
return 0;
}
if (arg_sign_value(cmd, dataalignmentoffset_ARG, SIGN_NONE) == SIGN_MINUS) {
cleanup: update messages
2017-06-23 11:59:12 +03:00
log_error("Physical volume data alignment offset may not be negative.");
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
return 0;
}
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
pp->pva.data_alignment_offset = arg_uint64_value(cmd, dataalignmentoffset_ARG, UINT64_C(0));
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
if (pp->pva.data_alignment_offset > UINT32_MAX) {
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
log_error("Physical volume data alignment offset is too big.");
return 0;
}
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
if ((pp->pva.data_alignment + pp->pva.data_alignment_offset) &&
(pp->pva.pe_start != PV_PE_START_CALC)) {
if ((pp->pva.data_alignment ? pp->pva.pe_start % pp->pva.data_alignment : pp->pva.pe_start) != pp->pva.data_alignment_offset) {
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
log_warn("WARNING: Ignoring data alignment %s"
cleanup: update messages
2017-06-23 11:59:12 +03:00
" incompatible with restored pe_start value %s.",
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
display_size(cmd, pp->pva.data_alignment + pp->pva.data_alignment_offset),
display_size(cmd, pp->pva.pe_start));
pp->pva.data_alignment = 0;
pp->pva.data_alignment_offset = 0;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
}
if (arg_sign_value(cmd, metadatasize_ARG, SIGN_NONE) == SIGN_MINUS) {
log_error("Metadata size may not be negative.");
return 0;
}
if (arg_sign_value(cmd, bootloaderareasize_ARG, SIGN_NONE) == SIGN_MINUS) {
log_error("Bootloader area size may not be negative.");
return 0;
}
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
pp->pva.pvmetadatasize = arg_uint64_value(cmd, metadatasize_ARG, UINT64_C(0));
Place the first PE at 1 MiB for all defaults . When using default settings, this commit should change nothing. The first PE continues to be placed at 1 MiB resulting in a metadata area size of 1020 KiB (for 4K page sizes; slightly smaller for larger page sizes.) . When default_data_alignment is disabled in lvm.conf, align pe_start at 1 MiB, based on a default metadata area size that adapts to the page size. Previously, disabling this option would result in mda_size that was too small for common use, and produced a 64 KiB aligned pe_start. . Customized pe_start and mda_size values continue to be set as before in lvm.conf and command line. . Remove the configure option for setting default_data_alignment at build time. . Improve alignment related option descriptions. . Add section about alignment to pvcreate man page. Previously, DEFAULT_PVMETADATASIZE was 255 sectors. However, the fact that the config setting named "default_data_alignment" has a default value of 1 (MiB) meant that DEFAULT_PVMETADATASIZE was having no effect. The metadata area size is the space between the start of the metadata area (page size offset from the start of the device) and the first PE (1 MiB by default due to default_data_alignment 1.) The result is a 1020 KiB metadata area on machines with 4KiB page size (1024 KiB - 4 KiB), and smaller on machines with larger page size. If default_data_alignment was set to 0 (disabled), then DEFAULT_PVMETADATASIZE 255 would take effect, and produce a metadata area that was 188 KiB and pe_start of 192 KiB. This was too small for common use. This is fixed by making the default metadata area size a computed value that matches the value produced by default_data_alignment.
2018-11-14 00:00:11 +03:00
if (!pp->pva.pvmetadatasize) {
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
pp->pva.pvmetadatasize = find_config_tree_int(cmd, metadata_pvmetadatasize_CFG, NULL);
Place the first PE at 1 MiB for all defaults . When using default settings, this commit should change nothing. The first PE continues to be placed at 1 MiB resulting in a metadata area size of 1020 KiB (for 4K page sizes; slightly smaller for larger page sizes.) . When default_data_alignment is disabled in lvm.conf, align pe_start at 1 MiB, based on a default metadata area size that adapts to the page size. Previously, disabling this option would result in mda_size that was too small for common use, and produced a 64 KiB aligned pe_start. . Customized pe_start and mda_size values continue to be set as before in lvm.conf and command line. . Remove the configure option for setting default_data_alignment at build time. . Improve alignment related option descriptions. . Add section about alignment to pvcreate man page. Previously, DEFAULT_PVMETADATASIZE was 255 sectors. However, the fact that the config setting named "default_data_alignment" has a default value of 1 (MiB) meant that DEFAULT_PVMETADATASIZE was having no effect. The metadata area size is the space between the start of the metadata area (page size offset from the start of the device) and the first PE (1 MiB by default due to default_data_alignment 1.) The result is a 1020 KiB metadata area on machines with 4KiB page size (1024 KiB - 4 KiB), and smaller on machines with larger page size. If default_data_alignment was set to 0 (disabled), then DEFAULT_PVMETADATASIZE 255 would take effect, and produce a metadata area that was 188 KiB and pe_start of 192 KiB. This was too small for common use. This is fixed by making the default metadata area size a computed value that matches the value produced by default_data_alignment.
2018-11-14 00:00:11 +03:00
if (!pp->pva.pvmetadatasize)
pp->pva.pvmetadatasize = get_default_pvmetadatasize_sectors();
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
pp->pva.pvmetadatacopies = arg_int_value(cmd, pvmetadatacopies_ARG, -1);
if (pp->pva.pvmetadatacopies < 0)
pp->pva.pvmetadatacopies = find_config_tree_int(cmd, metadata_pvmetadatacopies_CFG, NULL);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
pp->pva.ba_size = arg_uint64_value(cmd, bootloaderareasize_ARG, pp->pva.ba_size);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
return 1;
}
enum {
PROMPT_PVCREATE_PV_IN_VG = 1,
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
PROMPT_PVREMOVE_PV_IN_VG = 2,
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
PROMPT_PVCREATE_DEV_SIZE = 4,
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
};
enum {
PROMPT_ANSWER_NO = 1,
PROMPT_ANSWER_YES = 2
};
/*
* When a prompt entry is created, save any strings or info
* in this struct that are needed for the prompt messages.
* The VG/PV structs are not be available when the prompt
* is run.
*/
struct pvcreate_prompt {
struct dm_list list;
uint32_t type;
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
uint64_t size;
uint64_t new_size;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
const char *pv_name;
const char *vg_name;
struct device *dev;
int answer;
unsigned abort_command : 1;
unsigned vg_name_unknown : 1;
};
struct pvcreate_device {
struct dm_list list;
const char *name;
struct device *dev;
char pvid[ID_LEN + 1];
const char *vg_name;
int wiped;
unsigned is_not_pv : 1; /* device is not a PV */
unsigned is_orphan_pv : 1; /* device is an orphan PV */
unsigned is_vg_pv : 1; /* device is a PV used in a VG */
unsigned is_used_unknown_pv : 1; /* device is a PV used in an unknown VG */
};
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
/*
* If a PV is in a VG, and pvcreate or pvremove is run on it:
*
* pvcreate|pvremove -f : fails
* pvcreate|pvremove -y : fails
* pvcreate|pvremove -f -y : fails
* pvcreate|pvremove -ff : get y/n prompt
* pvcreate|pvremove -ff -y : succeeds
*
* FIXME: there are a lot of various phrasings used depending on the
* command and specific case. Find some similar way to phrase these.
*/
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
static void _check_pvcreate_prompt(struct cmd_context *cmd,
replace pvcreate_params with pvcreate_each_params "pvcreate_each_params" was a temporary name used to transition from the old "pvcreate_params". Remove the old pvcreate_params struct and rename the new pvcreate_each_params struct to pvcreate_params. Rename various pvcreate_each_params terms to simply pvcreate_params.
2016-02-19 00:38:23 +03:00
struct pvcreate_params *pp,
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
struct pvcreate_prompt *prompt,
int ask)
{
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
const char *vgname = prompt->vg_name ? prompt->vg_name : "<unknown>";
const char *pvname = prompt->pv_name;
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
int answer_yes = 0;
int answer_no = 0;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
/* The VG name can be unknown when the PV is used but metadata is not available */
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
if (prompt->type & PROMPT_PVCREATE_PV_IN_VG) {
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
if (pp->force != DONT_PROMPT_OVERRIDE) {
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
answer_no = 1;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
if (prompt->vg_name_unknown) {
Use a common message for a used PV Change some inconsistent messages and adopt the new wording "PV %s is used by" in place of "PV %s is marked as belonging to" or "PV %s belongs to".
2016-02-25 23:12:08 +03:00
log_error("PV %s is used by a VG but its metadata is missing.", pvname);
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
log_error("Can't initialize PV '%s' without -ff.", pvname);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
} else if (!strcmp(command_name(cmd), "pvcreate")) {
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
log_error("Can't initialize physical volume \"%s\" of volume group \"%s\" without -ff", pvname, vgname);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
} else {
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
log_error("Physical volume '%s' is already in volume group '%s'", pvname, vgname);
log_error("Unable to add physical volume '%s' to volume group '%s'", pvname, vgname);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
} else if (pp->yes) {
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
answer_yes = 1;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
} else if (ask) {
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
if (yes_no_prompt("Really INITIALIZE physical volume \"%s\" of volume group \"%s\" [y/n]? ", pvname, vgname) == 'n') {
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
answer_no = 1;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
} else {
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
answer_yes = 1;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
log_warn("WARNING: Forcing physical volume creation on %s of volume group \"%s\"", pvname, vgname);
}
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
}
if (prompt->type & PROMPT_PVCREATE_DEV_SIZE) {
if (pp->yes) {
log_warn("WARNING: Faking size of PV %s. Don't write outside real device.", pvname);
answer_yes = 1;
} else if (ask) {
if (prompt->new_size != prompt->size) {
if (yes_no_prompt("WARNING: %s: device size %s does not match requested size %s. Proceed? [y/n]: ", pvname,
tidy: drop unneeded cast Avoid casting to the same type.
2017-07-20 10:57:09 +03:00
display_size(cmd, prompt->size),
display_size(cmd, prompt->new_size)) == 'n') {
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
answer_no = 1;
} else {
answer_yes = 1;
log_warn("WARNING: Faking size of PV %s. Don't write outside real device.", pvname);
}
}
}
}
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
if (prompt->type & PROMPT_PVREMOVE_PV_IN_VG) {
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
if (pp->force != DONT_PROMPT_OVERRIDE) {
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
answer_no = 1;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
if (prompt->vg_name_unknown)
Use a common message for a used PV Change some inconsistent messages and adopt the new wording "PV %s is used by" in place of "PV %s is marked as belonging to" or "PV %s belongs to".
2016-02-25 23:12:08 +03:00
log_error("PV %s is used by a VG but its metadata is missing.", pvname);
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
else
Use a common message for a used PV Change some inconsistent messages and adopt the new wording "PV %s is used by" in place of "PV %s is marked as belonging to" or "PV %s belongs to".
2016-02-25 23:12:08 +03:00
log_error("PV %s is used by VG %s so please use vgreduce first.", pvname, vgname);
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
log_error("(If you are certain you need pvremove, then confirm by using --force twice.)");
} else if (pp->yes) {
cleanup: update messages
2017-06-23 11:59:12 +03:00
log_warn("WARNING: PV %s is used by VG %s.", pvname, vgname);
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
answer_yes = 1;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
} else if (ask) {
cleanup: update messages
2017-06-23 11:59:12 +03:00
log_warn("WARNING: PV %s is used by VG %s.", pvname, vgname);
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
if (yes_no_prompt("Really WIPE LABELS from physical volume \"%s\" of volume group \"%s\" [y/n]? ", pvname, vgname) == 'n')
answer_no = 1;
else
answer_yes = 1;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
}
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
if (answer_yes && answer_no) {
all: fix typos
2020-10-03 14:52:37 +03:00
log_warn("WARNING: prompt answer yes is overridden by prompt answer no.");
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
answer_yes = 0;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
/*
* no answer is valid when not asking the user.
* the caller uses this to check if all the prompts
* can be answered automatically without prompts.
*/
if (!ask && !answer_yes && !answer_no)
return;
if (answer_no)
prompt->answer = PROMPT_ANSWER_NO;
else if (answer_yes)
prompt->answer = PROMPT_ANSWER_YES;
/*
* Mostly historical messages. Other messages above could be moved
* here to separate the answer logic from the messages.
*/
if ((prompt->type & (PROMPT_PVCREATE_DEV_SIZE | PROMPT_PVCREATE_PV_IN_VG)) &&
(prompt->answer == PROMPT_ANSWER_NO))
log_error("%s: physical volume not initialized.", pvname);
if ((prompt->type & PROMPT_PVREMOVE_PV_IN_VG) &&
(prompt->answer == PROMPT_ANSWER_NO))
log_error("%s: physical volume label not removed.", pvname);
if ((prompt->type & PROMPT_PVREMOVE_PV_IN_VG) &&
(prompt->answer == PROMPT_ANSWER_YES) &&
(pp->force == DONT_PROMPT_OVERRIDE))
log_warn("WARNING: Wiping physical volume label from %s of volume group \"%s\".", pvname, vgname);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
static struct pvcreate_device *_pvcreate_list_find_dev(struct dm_list *devices, struct device *dev)
{
struct pvcreate_device *pd;
dm_list_iterate_items(pd, devices) {
if (pd->dev == dev)
return pd;
}
return NULL;
}
static struct pvcreate_device *_pvcreate_list_find_name(struct dm_list *devices, const char *name)
{
struct pvcreate_device *pd;
dm_list_iterate_items(pd, devices) {
if (!strcmp(pd->name, name))
return pd;
}
return NULL;
}
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
static int _pvcreate_check_used(struct cmd_context *cmd,
struct pvcreate_params *pp,
struct pvcreate_device *pd)
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
{
struct pvcreate_prompt *prompt;
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
uint64_t size = 0;
uint64_t new_size = 0;
int need_size_prompt = 0;
int need_vg_prompt = 0;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
struct lvmcache_info *info;
const char *vgname;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Checking %s for pvcreate %.32s.",
dev_name(pd->dev), pd->dev->pvid[0] ? pd->dev->pvid : "");
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (!pd->dev->pvid[0]) {
log_debug("Check pvcreate arg %s no PVID found", dev_name(pd->dev));
pd->is_not_pv = 1;
return 1;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
/*
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
* Don't allow using a device with duplicates.
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (lvmcache_pvid_in_unused_duplicates(pd->dev->pvid)) {
log_error("Cannot use device %s with duplicates.", dev_name(pd->dev));
dm_list_move(&pp->arg_fail, &pd->list);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
return 0;
}
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (!(info = lvmcache_info_from_pvid(pd->dev->pvid, pd->dev, 0))) {
log_error("Failed to read lvm info for %s PVID %s.", dev_name(pd->dev), pd->dev->pvid);
vgcreate, pvcreate, vgextend: don't use a device with duplicates If duplicate orphan PVs exist, don't allow one of them to be used for vgcreate/pvcreate/vgextend.
2016-06-06 23:39:51 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
return 0;
vgcreate, pvcreate, vgextend: don't use a device with duplicates If duplicate orphan PVs exist, don't allow one of them to be used for vgcreate/pvcreate/vgextend.
2016-06-06 23:39:51 +03:00
}
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
vgname = lvmcache_vgname_from_info(info);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/*
* What kind of device is this: an orphan PV, an uninitialized/unused
* device, a PV used in a VG.
*/
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (vgname && !is_orphan_vg(vgname)) {
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/* Device is a PV used in a VG. */
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Check pvcreate arg %s found vg %s.", dev_name(pd->dev), vgname);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pd->is_vg_pv = 1;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
pd->vg_name = dm_pool_strdup(cmd->mem, vgname);
} else if (!vgname || (vgname && is_orphan_vg(vgname))) {
uint32_t ext_flags = lvmcache_ext_flags(info);
if (ext_flags & PV_EXT_USED) {
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/* Device is used in an unknown VG. */
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Check pvcreate arg %s found EXT_USED flag.", dev_name(pd->dev));
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pd->is_used_unknown_pv = 1;
} else {
/* Device is an orphan PV. */
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Check pvcreate arg %s is orphan.", dev_name(pd->dev));
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pd->is_orphan_pv = 1;
}
Remove lvm1 and pool disk formats There are likely more bits of code that can be removed, e.g. lvm1/pool-specific bits of code that were identified using FMT flags. The vgconvert command can likely be reduced further. The lvm1-specific config settings should probably have some other fields set for proper deprecation.
2018-04-28 00:22:46 +03:00
pp->orphan_vg_name = FMT_TEXT_ORPHAN_VG_NAME;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
if (arg_is_set(cmd, setphysicalvolumesize_ARG)) {
new_size = arg_uint64_value(cmd, setphysicalvolumesize_ARG, UINT64_C(0));
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (!dev_get_size(pd->dev, &size)) {
log_error("Can't get device size of %s.", dev_name(pd->dev));
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
return 0;
tidy: prefer not using else after return clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
2017-07-19 17:16:12 +03:00
}
if (new_size != size)
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
need_size_prompt = 1;
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/*
* pvcreate is being run on this device, and it's not a PV,
* or is an orphan PV. Neither case requires a prompt.
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
* Or, pvcreate is being run on this device, but the device
* is already a PV in a VG. A prompt or force option is required
* to use it.
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
if (pd->is_orphan_pv || pd->is_not_pv)
need_vg_prompt = 0;
else
need_vg_prompt = 1;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (!need_size_prompt && !need_vg_prompt)
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
return 1;
if (!(prompt = dm_pool_zalloc(cmd->mem, sizeof(*prompt)))) {
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
return_0;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
prompt->dev = pd->dev;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
prompt->pv_name = dm_pool_strdup(cmd->mem, dev_name(pd->dev));
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
prompt->size = size;
prompt->new_size = new_size;
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
if (pd->is_used_unknown_pv)
prompt->vg_name_unknown = 1;
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
else if (need_vg_prompt)
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
prompt->vg_name = dm_pool_strdup(cmd->mem, vgname);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
if (need_size_prompt)
prompt->type |= PROMPT_PVCREATE_DEV_SIZE;
if (need_vg_prompt)
prompt->type |= PROMPT_PVCREATE_PV_IN_VG;
dm_list_add(&pp->prompts, &prompt->list);
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
return 1;
}
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
static int _pvremove_check_used(struct cmd_context *cmd,
struct pvcreate_params *pp,
struct pvcreate_device *pd)
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
{
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
struct pvcreate_prompt *prompt;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
struct lvmcache_info *info;
const char *vgname = NULL;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Checking %s for pvremove %.32s.",
dev_name(pd->dev), pd->dev->pvid[0] ? pd->dev->pvid : "");
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
/*
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
* Is there a pv here already?
* If not, this is an error unless you used -f.
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
*/
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (!pd->dev->pvid[0]) {
log_debug("Check pvremove arg %s no PVID found", dev_name(pd->dev));
if (pp->force)
return 1;
pd->is_not_pv = 1;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
}
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (!(info = lvmcache_info_from_pvid(pd->dev->pvid, pd->dev, 0))) {
if (pp->force)
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
return 1;
pvremove: use consistent error message When the device is not a PV print "No PV found on device ..." instead of "Failed to read lvm info for ... PVID ." an earlier check had been added with a different message for the same condition.
2021-05-04 21:03:25 +03:00
log_error("No PV found on device %s.", dev_name(pd->dev));
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
return 0;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
}
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (info)
vgname = lvmcache_vgname_from_info(info);
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
/*
* What kind of device is this: an orphan PV, an uninitialized/unused
* device, a PV used in a VG.
*/
pvremove: device check doesn't require label_read It just needs to check if the device was found during the scan, which means checking if it exists in lvmcache.
2018-02-09 21:43:12 +03:00
if (pd->is_not_pv) {
/* Device is not a PV. */
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Check pvremove arg %s device is not a PV.", dev_name(pd->dev));
pvremove: device check doesn't require label_read It just needs to check if the device was found during the scan, which means checking if it exists in lvmcache.
2018-02-09 21:43:12 +03:00
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
} else if (vgname && !is_orphan_vg(vgname)) {
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
/* Device is a PV used in a VG. */
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Check pvremove arg %s found vg %s.", dev_name(pd->dev), vgname);
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
pd->is_vg_pv = 1;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
pd->vg_name = dm_pool_strdup(cmd->mem, vgname);
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
} else if (info && (!vgname || (vgname && is_orphan_vg(vgname)))) {
uint32_t ext_flags = lvmcache_ext_flags(info);
if (ext_flags & PV_EXT_USED) {
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
/* Device is used in an unknown VG. */
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Check pvremove arg %s found EXT_USED flag.", dev_name(pd->dev));
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
pd->is_used_unknown_pv = 1;
} else {
/* Device is an orphan PV. */
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Check pvremove arg %s is orphan.", dev_name(pd->dev));
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
pd->is_orphan_pv = 1;
}
Remove lvm1 and pool disk formats There are likely more bits of code that can be removed, e.g. lvm1/pool-specific bits of code that were identified using FMT flags. The vgconvert command can likely be reduced further. The lvm1-specific config settings should probably have some other fields set for proper deprecation.
2018-04-28 00:22:46 +03:00
pp->orphan_vg_name = FMT_TEXT_ORPHAN_VG_NAME;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
}
if (pd->is_not_pv) {
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_error("No PV found on device %s.", dev_name(pd->dev));
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
return 0;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
}
/*
* pvremove is being run on this device, and it's not a PV,
* or is an orphan PV. Neither case requires a prompt.
*/
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (pd->is_orphan_pv)
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
return 1;
/*
* pvremove is being run on this device, but the device is in a VG.
* A prompt or force option is required to use it.
*/
if (!(prompt = dm_pool_zalloc(cmd->mem, sizeof(*prompt)))) {
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
return_0;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
}
prompt->dev = pd->dev;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
prompt->pv_name = dm_pool_strdup(cmd->mem, dev_name(pd->dev));
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
if (pd->is_used_unknown_pv)
prompt->vg_name_unknown = 1;
else
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
prompt->vg_name = dm_pool_strdup(cmd->mem, vgname);
pvcreate: add prompt when setting dev size If the device size does not match the size requested by --setphysicalvolumesize, then prompt the user. Make the pvcreate checking/prompting code handle multiple prompts for the same device, since the new prompt can be in addition to the existing prompt when the PV is in a VG.
2017-04-27 20:13:09 +03:00
prompt->type |= PROMPT_PVREMOVE_PV_IN_VG;
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
dm_list_add(&pp->prompts, &prompt->list);
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
return 1;
}
static int _confirm_check_used(struct cmd_context *cmd,
struct pvcreate_params *pp,
struct pvcreate_device *pd)
{
struct lvmcache_info *info = NULL;
const char *vgname = NULL;
int is_not_pv = 0;
log_debug("Checking %s to confirm %.32s.",
dev_name(pd->dev), pd->dev->pvid[0] ? pd->dev->pvid : "");
if (!pd->dev->pvid[0]) {
log_debug("Check confirm arg %s no PVID found", dev_name(pd->dev));
is_not_pv = 1;
}
if (!(info = lvmcache_info_from_pvid(pd->dev->pvid, pd->dev, 0))) {
log_debug("Check confirm arg %s no info.", dev_name(pd->dev));
is_not_pv = 1;
}
if (info)
vgname = lvmcache_vgname_from_info(info);
/*
* What kind of device is this: an orphan PV, an uninitialized/unused
* device, a PV used in a VG.
*/
if (vgname && !is_orphan_vg(vgname)) {
/* Device is a PV used in a VG. */
if (pd->is_orphan_pv || pd->is_not_pv || pd->is_used_unknown_pv) {
/* In first check it was an orphan or unused. */
goto fail;
}
if (pd->is_vg_pv && pd->vg_name && strcmp(pd->vg_name, vgname)) {
/* In first check it was in a different VG. */
goto fail;
}
} else if (info && (!vgname || is_orphan_vg(vgname))) {
uint32_t ext_flags = lvmcache_ext_flags(info);
/* Device is an orphan PV. */
if (pd->is_not_pv) {
/* In first check it was not a PV. */
goto fail;
}
if (pd->is_vg_pv) {
/* In first check it was in a VG. */
goto fail;
}
if ((ext_flags & PV_EXT_USED) && !pd->is_used_unknown_pv) {
/* In first check it was different. */
goto fail;
}
if (!(ext_flags & PV_EXT_USED) && pd->is_used_unknown_pv) {
/* In first check it was different. */
goto fail;
}
} else if (is_not_pv) {
/* Device is not a PV. */
if (pd->is_orphan_pv || pd->is_used_unknown_pv) {
/* In first check it was an orphan PV. */
goto fail;
}
if (pd->is_vg_pv) {
/* In first check it was in a VG. */
goto fail;
}
}
return 1;
cleanup: missplaced . Remove misplaced '.' after '?' Drop extra 'stack;' after log_debug().
2016-03-01 19:20:47 +03:00
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
fail:
log_error("Cannot use device %s: it changed during prompt.", dev_name(pd->dev));
dm_list_move(&pp->arg_fail, &pd->list);
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
return 1;
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/*
* This can be used by pvcreate, vgcreate and vgextend to create PVs. The
* callers need to set up the pvcreate_each_params structure based on command
* line args. This includes the pv_names field which specifies the devices to
* create PVs on.
*
* This function returns 0 (failed) if the caller requires all specified
* devices to be created, and any of those devices are not found, or any of
* them cannot be created.
*
* This function returns 1 (success) if the caller requires all specified
* devices to be created, and all are created, or if the caller does not
* require all specified devices to be created and one or more were created.
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
*
* Process of opening, scanning and filtering:
*
* - label scan and filter all devs
* . open ro
* . standard label scan at the start of command
* . done prior to this function
*
* - label scan and filter dev args
* . label_scan_devs(&scan_devs) in this function
* . open ro
* . uses full md component check
* . typically the first scan and filter of pvcreate devs
*
* - close and reopen dev args
* . open rw and excl
* . done by label_scan_devs_excl
*
* - repeat label scan and filter dev args
* . using reopened rw excl fd
* . since something could have used dev
* in the small window between close and reopen
*
* - wipe and write new headers
* . using reopened rw excl fd
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
int pvcreate_each_device(struct cmd_context *cmd,
struct processing_handle *handle,
replace pvcreate_params with pvcreate_each_params "pvcreate_each_params" was a temporary name used to transition from the old "pvcreate_params". Remove the old pvcreate_params struct and rename the new pvcreate_each_params struct to pvcreate_params. Rename various pvcreate_each_params terms to simply pvcreate_params.
2016-02-19 00:38:23 +03:00
struct pvcreate_params *pp)
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
{
struct pvcreate_device *pd, *pd2;
struct pvcreate_prompt *prompt, *prompt2;
struct physical_volume *pv;
struct volume_group *orphan_vg;
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
struct dm_list remove_duplicates;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
struct dm_list arg_sort;
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
struct dm_list scan_devs;
scan: use separate fd for bcache Create a new dev->bcache_fd that the scanning code owns and is in charge of opening/closing. This prevents other parts of lvm code (which do various open/close) from interfering with the bcache fd. A number of dev_open and dev_close are removed from the reading path since the read path now uses the bcache. With that in place, open(O_EXCL) for pvcreate/pvremove can then be fixed. That wouldn't work previously because of other open fds.
2018-02-13 17:58:35 +03:00
struct dm_list rescan_devs;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
struct pv_list *pvl;
struct pv_list *vgpvl;
scan: use separate fd for bcache Create a new dev->bcache_fd that the scanning code owns and is in charge of opening/closing. This prevents other parts of lvm code (which do various open/close) from interfering with the bcache fd. A number of dev_open and dev_close are removed from the reading path since the read path now uses the bcache. With that in place, open(O_EXCL) for pvcreate/pvremove can then be fixed. That wouldn't work previously because of other open fds.
2018-02-13 17:58:35 +03:00
struct device_list *devl;
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
char pvid[ID_LEN + 1] __attribute__((aligned(8))) = { 0 };
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
const char *pv_name;
vgcreate/vgextend: restrict PVs with mixed block sizes Avoid having PVs with different logical block sizes in the same VG. This prevents LVs from having mixed block sizes, which can produce file system errors. The new config setting devices/allow_mixed_block_sizes (default 0) can be changed to 1 to return to the unrestricted mode.
2019-08-01 18:06:47 +03:00
unsigned int physical_block_size, logical_block_size;
unsigned int prev_pbs = 0, prev_lbs = 0;
command struct: remove command name refs Change run time access to the command_name struct cmd->cname instead of indirectly through cmd->command->cname. This removes the two run time fields from struct command.
2017-01-14 00:08:51 +03:00
int must_use_all = (cmd->cname->flags & MUST_USE_ALL_ARGS);
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
int unlocked_for_prompts = 0;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
int found;
cleanup: use matching signed number comparation
2017-02-12 20:18:54 +03:00
unsigned i;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
dbus: add notification from commands When a command modifies a PV or VG, or changes the activation state of an LV, it will send a dbus notification when the command is finished. This can be enabled/disabled with a config setting.
2016-02-22 18:42:03 +03:00
set_pv_notify(cmd);
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
dm_list_init(&remove_duplicates);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
dm_list_init(&arg_sort);
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
dm_list_init(&scan_devs);
scan: use separate fd for bcache Create a new dev->bcache_fd that the scanning code owns and is in charge of opening/closing. This prevents other parts of lvm code (which do various open/close) from interfering with the bcache fd. A number of dev_open and dev_close are removed from the reading path since the read path now uses the bcache. With that in place, open(O_EXCL) for pvcreate/pvremove can then be fixed. That wouldn't work previously because of other open fds.
2018-02-13 17:58:35 +03:00
dm_list_init(&rescan_devs);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
handle->custom_handle = pp;
/*
* Create a list entry for each name arg.
*/
for (i = 0; i < pp->pv_count; i++) {
dm_unescape_colons_and_at_signs(pp->pv_names[i], NULL, NULL);
pv_name = pp->pv_names[i];
if (!(pd = dm_pool_zalloc(cmd->mem, sizeof(*pd)))) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("alloc failed.");
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
return 0;
}
if (!(pd->name = dm_pool_strdup(cmd->mem, pv_name))) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("strdup failed.");
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
return 0;
}
dm_list_add(&pp->arg_devices, &pd->list);
}
pvcreate, pvremove: translate arg name to device once Rather than doing repeated translations from name to device when comparing args to existing PVs, do one translation of the arg names and saving the device, before checking existing PVs.
2016-05-04 19:28:28 +03:00
/*
* Translate arg names into struct device's.
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
*
* lvmcache_label_scan has already been run by the caller.
* It has likely found and filtered pvremove args, but often
* not pvcreate args, since pvcreate args are not typically PVs
* yet (but may be.)
*
* We call label_scan_devs on the args, using the full
* md filter (the previous scan likely did not use the
* full md filter - we really only need to check the
* command args to ensure they are not md components.)
*/
dm_list_iterate_items_safe(pd, pd2, &pp->arg_devices) {
struct device *dev;
/* No filter used here */
devices: initial use of existing option Use dev_cache_get_existing() in a few common, high level locations where it's obvious that only existing dev-cache entries are wanted. This can be expanded and used in more locations (or dev_cache_get can stop creating new entries.)
2022-02-25 01:10:37 +03:00
if (!(dev = dev_cache_get_existing(cmd, pd->name, NULL))) {
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
log_error("No device found for %s.", pd->name);
dm_list_del(&pd->list);
dm_list_add(&pp->arg_fail, &pd->list);
continue;
}
if (!(devl = dm_pool_zalloc(cmd->mem, sizeof(*devl))))
goto bad;
devl->dev = dev;
pd->dev = dev;
dm_list_add(&scan_devs, &devl->list);
}
if (dm_list_empty(&pp->arg_devices))
goto_bad;
/*
* Clear the filtering results from lvmcache_label_scan because we are
* going to rerun the filters and don't want to get the results saved
* by the prior filtering. The filtering in label scan will use full
* md filter.
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
*
* We allow pvcreate to look outside devices file here to find
* the target device, in case the user has not added the device
* being pvcreated to the devices file.
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
*/
dm_list_iterate_items(devl, &scan_devs)
cmd->filter->wipe(cmd, cmd->filter, devl->dev, NULL);
cmd->use_full_md_check = 1;
pvremove: apply devices file pvremove was wrongly allowed to operate on a device not listed in the devices file.
2021-08-27 22:48:33 +03:00
if (cmd->enable_devices_file && !pp->is_remove)
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
cmd->filter_deviceid_skip = 1;
log_debug("Scanning and filtering device args (%u).", dm_list_size(&scan_devs));
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
label_scan_devs(cmd, cmd->filter, &scan_devs);
/*
* Check if the filtering done by label scan excluded any devices.
pvcreate, pvremove: translate arg name to device once Rather than doing repeated translations from name to device when comparing args to existing PVs, do one translation of the arg names and saving the device, before checking existing PVs.
2016-05-04 19:28:28 +03:00
*/
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
dm_list_iterate_items_safe(pd, pd2, &pp->arg_devices) {
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
if (!cmd->filter->passes_filter(cmd, cmd->filter, pd->dev, NULL)) {
improve message for invalid device arg for pvcreate, pvremove, vgcreate, vgextend.
2020-10-01 20:19:27 +03:00
log_error("Cannot use %s: %s", pd->name, devname_error_reason(pd->name));
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
dm_list_del(&pd->list);
dm_list_add(&pp->arg_fail, &pd->list);
}
}
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
cmd->filter_deviceid_skip = 0;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
/*
* Can the command continue if some specified devices were not found?
*/
if (must_use_all && !dm_list_empty(&pp->arg_fail)) {
log_error("Command requires all devices to be found.");
cleanup: no backtraces needed after log_error Reduce double backtracing.
2021-03-09 13:42:29 +03:00
return 0;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
}
pvcreate, pvremove: translate arg name to device once Rather than doing repeated translations from name to device when comparing args to existing PVs, do one translation of the arg names and saving the device, before checking existing PVs.
2016-05-04 19:28:28 +03:00
vgcreate/vgextend: restrict PVs with mixed block sizes Avoid having PVs with different logical block sizes in the same VG. This prevents LVs from having mixed block sizes, which can produce file system errors. The new config setting devices/allow_mixed_block_sizes (default 0) can be changed to 1 to return to the unrestricted mode.
2019-08-01 18:06:47 +03:00
/*
* Check for consistent block sizes.
*/
if (pp->check_consistent_block_size) {
dm_list_iterate_items(pd, &pp->arg_devices) {
logical_block_size = 0;
physical_block_size = 0;
if (!dev_get_direct_block_sizes(pd->dev, &physical_block_size, &logical_block_size)) {
log_warn("WARNING: Unknown block size for device %s.", dev_name(pd->dev));
continue;
}
if (!logical_block_size) {
log_warn("WARNING: Unknown logical_block_size for device %s.", dev_name(pd->dev));
continue;
}
if (!prev_lbs) {
prev_lbs = logical_block_size;
prev_pbs = physical_block_size;
continue;
}
if (prev_lbs == logical_block_size) {
/* Require lbs to match, just warn about unmatching pbs. */
if (!cmd->allow_mixed_block_sizes && prev_pbs && physical_block_size &&
(prev_pbs != physical_block_size))
log_warn("WARNING: Devices have inconsistent physical block sizes (%u and %u).",
prev_pbs, physical_block_size);
continue;
}
if (!cmd->allow_mixed_block_sizes) {
log_error("Devices have inconsistent logical block sizes (%u and %u).",
prev_lbs, logical_block_size);
log_print("See lvm.conf allow_mixed_block_sizes.");
return 0;
}
}
}
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
/* check_used moves pd entries into the arg_fail list if pvcreate/pvremove is disallowed */
dm_list_iterate_items_safe(pd, pd2, &pp->arg_devices) {
if (pp->is_remove)
_pvremove_check_used(cmd, pp, pd);
else
_pvcreate_check_used(cmd, pp, pd);
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/*
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
* If the user specified a uuid for the new PV, check
* if a PV on another dev is already using that uuid.
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
if (!pp->is_remove && pp->uuid_str) {
struct device *dev;
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
if ((dev = lvmcache_device_from_pv_id(cmd, &pp->pva.id, NULL))) {
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
dm_list_iterate_items_safe(pd, pd2, &pp->arg_devices) {
if (pd->dev != dev) {
log_error("UUID %s already in use on \"%s\".", pp->uuid_str, dev_name(dev));
dm_list_move(&pp->arg_fail, &pd->list);
}
}
}
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
/*
* Special case: pvremove -ff is allowed to clear a duplicate device in
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
* the unchosen duplicates list. We save them here and erase them below.
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
*/
if (pp->is_remove && (pp->force == DONT_PROMPT_OVERRIDE) &&
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
!dm_list_empty(&pp->arg_devices) && lvmcache_has_duplicate_devs()) {
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
dm_list_iterate_items_safe(pd, pd2, &pp->arg_devices) {
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
if (lvmcache_dev_is_unused_duplicate(pd->dev)) {
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
log_debug("Check pvremove arg %s device is a duplicate.", dev_name(pd->dev));
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
dm_list_move(&remove_duplicates, &pd->list);
}
}
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/*
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
* Any devices not moved to arg_fail can be processed.
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
dm_list_splice(&pp->arg_process, &pp->arg_devices);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/*
* Can the command continue if some specified devices cannot be used?
*/
if (!dm_list_empty(&pp->arg_fail) && must_use_all)
goto_bad;
/*
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
* The command cannot continue if there are no devices to process.
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
if (dm_list_empty(&pp->arg_process) && dm_list_empty(&remove_duplicates)) {
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
log_debug("No devices to process.");
cleanup: missplaced . Remove misplaced '.' after '?' Drop extra 'stack;' after log_debug().
2016-03-01 19:20:47 +03:00
goto bad;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
/*
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
* Clear any prompts that have answers without asking the user.
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
dm_list_iterate_items_safe(prompt, prompt2, &pp->prompts) {
_check_pvcreate_prompt(cmd, pp, prompt, 0);
switch (prompt->answer) {
case PROMPT_ANSWER_YES:
/* The PV can be used, leave it on arg_process. */
dm_list_del(&prompt->list);
break;
case PROMPT_ANSWER_NO:
/* The PV cannot be used, remove it from arg_process. */
if ((pd = _pvcreate_list_find_dev(&pp->arg_process, prompt->dev)))
dm_list_move(&pp->arg_fail, &pd->list);
dm_list_del(&prompt->list);
break;
}
}
if (!dm_list_empty(&pp->arg_fail) && must_use_all)
goto_bad;
/*
* If no remaining prompts need a user response, then keep orphans
cleanup: remove blank spaces
2024-05-27 16:49:51 +03:00
* locked and go directly to the create steps.
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
if (dm_list_empty(&pp->prompts))
goto do_command;
/*
Remove checking for locked VGs A few places were calling a function to check if a VG lock was held. The only place it was actually needed is for pvcreate which wants to do its own locking (and scanning) around process_each_pv. The locking/scanning exceptions for pvcreate in process_each_pv/vg_read can be enabled by just passing a couple of flags instead of checking if the VG is already locked. This also means that these special cases won't be enabled unknowingly in other places where they shouldn't be used.
2018-06-11 20:25:52 +03:00
* Prompts require asking the user and make take some time, during
* which we don't want to block other commands. So, release the lock
* to prevent blocking other commands while we wait. After a response
* from the user, reacquire the lock, verify that the PVs were not used
* during the wait, then do the create steps.
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
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
lockf_global(cmd, "un");
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
unlocked_for_prompts = 1;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/*
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
* Process prompts that require asking the user. The global lock is
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
* not held, so there's no harm in waiting for a user to respond.
*/
dm_list_iterate_items_safe(prompt, prompt2, &pp->prompts) {
_check_pvcreate_prompt(cmd, pp, prompt, 1);
switch (prompt->answer) {
case PROMPT_ANSWER_YES:
/* The PV can be used, leave it on arg_process. */
dm_list_del(&prompt->list);
break;
case PROMPT_ANSWER_NO:
/* The PV cannot be used, remove it from arg_process. */
if ((pd = _pvcreate_list_find_dev(&pp->arg_process, prompt->dev)))
dm_list_move(&pp->arg_fail, &pd->list);
dm_list_del(&prompt->list);
break;
}
if (!dm_list_empty(&pp->arg_fail) && must_use_all)
debug: use just single label
2023-08-14 15:09:25 +03:00
goto_bad;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
if (sigint_caught())
debug: use just single label
2023-08-14 15:09:25 +03:00
goto_bad;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
if (prompt->abort_command)
debug: use just single label
2023-08-14 15:09:25 +03:00
goto_bad;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
/*
Remove checking for locked VGs A few places were calling a function to check if a VG lock was held. The only place it was actually needed is for pvcreate which wants to do its own locking (and scanning) around process_each_pv. The locking/scanning exceptions for pvcreate in process_each_pv/vg_read can be enabled by just passing a couple of flags instead of checking if the VG is already locked. This also means that these special cases won't be enabled unknowingly in other places where they shouldn't be used.
2018-06-11 20:25:52 +03:00
* Reacquire the lock that was released above before waiting, then
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
* check again that the devices can still be used. If the second check
Remove checking for locked VGs A few places were calling a function to check if a VG lock was held. The only place it was actually needed is for pvcreate which wants to do its own locking (and scanning) around process_each_pv. The locking/scanning exceptions for pvcreate in process_each_pv/vg_read can be enabled by just passing a couple of flags instead of checking if the VG is already locked. This also means that these special cases won't be enabled unknowingly in other places where they shouldn't be used.
2018-06-11 20:25:52 +03:00
* finds them changed, or can't find them any more, then they aren't
pvcreate,pvremove: fix reacquiring global lock after prompt When pvcreate/pvremove prompt the user, they first release the global lock, then acquire it again after the prompt, to avoid blocking other commands while waiting for a user response. This release/reacquire changes the locking order with respect to the hints flock (and potentially other locks). So, to avoid deadlock, use a nonblocking request when reacquiring the global lock.
2019-11-26 23:34:43 +03:00
* used. Use a non-blocking request when reacquiring to avoid
* potential deadlock since this is not the normal locking sequence.
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
*/
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
pvcreate,pvremove: fix reacquiring global lock after prompt When pvcreate/pvremove prompt the user, they first release the global lock, then acquire it again after the prompt, to avoid blocking other commands while waiting for a user response. This release/reacquire changes the locking order with respect to the hints flock (and potentially other locks). So, to avoid deadlock, use a nonblocking request when reacquiring the global lock.
2019-11-26 23:34:43 +03:00
if (!lockf_global_nonblock(cmd, "ex")) {
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
log_error("Failed to reacquire global lock after prompt.");
debug: use just single label
2023-08-14 15:09:25 +03:00
goto bad;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
do_command:
scan: use separate fd for bcache Create a new dev->bcache_fd that the scanning code owns and is in charge of opening/closing. This prevents other parts of lvm code (which do various open/close) from interfering with the bcache fd. A number of dev_open and dev_close are removed from the reading path since the read path now uses the bcache. With that in place, open(O_EXCL) for pvcreate/pvremove can then be fixed. That wouldn't work previously because of other open fds.
2018-02-13 17:58:35 +03:00
dm_list_iterate_items(pd, &pp->arg_process) {
if (!(devl = dm_pool_zalloc(cmd->mem, sizeof(*devl))))
goto bad;
devl->dev = pd->dev;
dm_list_add(&rescan_devs, &devl->list);
}
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
/*
* We want label_scan excl to repeat the filter check in case something
* changed to filter out a dev before we were able to get exclusive.
*/
dm_list_iterate_items(devl, &rescan_devs)
cmd->filter->wipe(cmd, cmd->filter, devl->dev, NULL);
pvremove: apply devices file pvremove was wrongly allowed to operate on a device not listed in the devices file.
2021-08-27 22:48:33 +03:00
if (cmd->enable_devices_file && !pp->is_remove)
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
cmd->filter_deviceid_skip = 1;
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
log_debug("Rescanning and filtering device args with exclusive open");
if (!label_scan_devs_excl(cmd, cmd->filter, &rescan_devs)) {
scan: use separate fd for bcache Create a new dev->bcache_fd that the scanning code owns and is in charge of opening/closing. This prevents other parts of lvm code (which do various open/close) from interfering with the bcache fd. A number of dev_open and dev_close are removed from the reading path since the read path now uses the bcache. With that in place, open(O_EXCL) for pvcreate/pvremove can then be fixed. That wouldn't work previously because of other open fds.
2018-02-13 17:58:35 +03:00
log_debug("Failed to rescan devs excl");
goto bad;
}
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
dm_list_iterate_items_safe(pd, pd2, &pp->arg_process) {
if (!cmd->filter->passes_filter(cmd, cmd->filter, pd->dev, NULL)) {
log_error("Cannot use %s: %s", pd->name, devname_error_reason(pd->name));
dm_list_del(&pd->list);
dm_list_add(&pp->arg_fail, &pd->list);
}
}
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
cmd->filter_deviceid_skip = 0;
pvcreate: clean up opening and filtering of args The args for pvcreate/pvremove (and vgcreate/vgextend when applicable) were not efficiently opened, scanned, and filtered. This change reorganizes the opening and filtering in the following steps: - label scan and filter all devs . open ro . standard label scan at the start of command - label scan and filter dev args . open ro . uses full md component check . typically the first scan and filter of pvcreate devs - close and reopen dev args . open rw and excl - repeat label scan and filter dev args . using reopened rw excl fd - wipe and write new headers . using reopened rw excl fd
2020-10-23 21:53:52 +03:00
if (dm_list_empty(&pp->arg_process) && dm_list_empty(&remove_duplicates)) {
log_debug("No devices to process.");
goto bad;
}
if (!dm_list_empty(&pp->arg_fail) && must_use_all)
goto_bad;
pvcreate/pvremove: reimplement device checks Reorganize checking the device args for pvcreate/pvremove to prepare for future changes. There should be no change in behavior. Stop the inverted use of process_each_pv, which pulled in a lot of unnecessary processing, and call the check functions on each device directly.
2020-06-23 21:19:11 +03:00
/*
* If the global lock was unlocked to wait for prompts, then
* devs could have changed while unlocked, so confirm that
* the devs are unchanged since check_used.
* Changed pd entries are moved to arg_fail.
*/
if (unlocked_for_prompts) {
dm_list_iterate_items_safe(pd, pd2, &pp->arg_process)
_confirm_check_used(cmd, pp, pd);
if (!dm_list_empty(&pp->arg_fail) && must_use_all)
goto_bad;
}
if (dm_list_empty(&pp->arg_process)) {
log_debug("No devices to process.");
goto bad;
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/*
* Reorder arg_process entries to match the original order of args.
*/
dm_list_splice(&arg_sort, &pp->arg_process);
for (i = 0; i < pp->pv_count; i++) {
if ((pd = _pvcreate_list_find_name(&arg_sort, pp->pv_names[i])))
dm_list_move(&pp->arg_process, &pd->list);
}
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
if (pp->is_remove)
dm_list_splice(&pp->arg_remove, &pp->arg_process);
else
dm_list_splice(&pp->arg_create, &pp->arg_process);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
/*
* Wipe signatures on devices being created.
*/
dm_list_iterate_items_safe(pd, pd2, &pp->arg_create) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_verbose("Wiping signatures on new PV %s.", pd->name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
if (!wipe_known_signatures(cmd, pd->dev, pd->name, TYPE_LVM1_MEMBER | TYPE_LVM2_MEMBER,
0, pp->yes, pp->force, &pd->wiped)) {
dm_list_move(&pp->arg_fail, &pd->list);
}
if (sigint_caught())
goto_bad;
}
if (!dm_list_empty(&pp->arg_fail) && must_use_all)
goto_bad;
/*
* Find existing orphan PVs that vgcreate or vgextend want to use.
* "preserve_existing" means that the command wants to use existing PVs
* and not recreate a new PV on top of an existing PV.
*/
if (pp->preserve_existing && pp->orphan_vg_name) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_debug("Using existing orphan PVs in %s.", pp->orphan_vg_name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
if (!(orphan_vg = vg_read_orphans(cmd, pp->orphan_vg_name))) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("Cannot read orphans VG %s.", pp->orphan_vg_name);
debug: more stacktrace corrections Continue previous patch dropping some unneeded stack traces after printed log_error/warn messages.
2016-11-25 15:46:06 +03:00
goto bad;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
dm_list_iterate_items_safe(pd, pd2, &pp->arg_create) {
if (!pd->is_orphan_pv)
continue;
if (!(pvl = dm_pool_alloc(cmd->mem, sizeof(*pvl)))) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("alloc pvl failed.");
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
continue;
}
found = 0;
dm_list_iterate_items(vgpvl, &orphan_vg->pvs) {
if (vgpvl->pv->dev == pd->dev) {
found = 1;
break;
}
}
if (found) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_debug("Using existing orphan PV %s.", pv_dev_name(vgpvl->pv));
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pvl->pv = vgpvl->pv;
dm_list_add(&pp->pvs, &pvl->list);
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
/* allow deviceidtype_ARG/deviceid_ARG ? */
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
memcpy(pvid, &pvl->pv->id.uuid, ID_LEN);
lvmdevices: use deviceidtype option strictly Only use the device id type specified by --deviceidtype, and fail if that type is not available for the device.
2022-09-15 17:45:21 +03:00
device_id_add(cmd, pd->dev, pvid, NULL, NULL, 0);
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
} else {
log_error("Failed to find PV %s", pd->name);
dm_list_move(&pp->arg_fail, &pd->list);
}
}
}
/*
* Create PVs on devices. Either create a new PV on top of an existing
* one (e.g. for pvcreate), or create a new PV on a device that is not
* a PV.
*/
dm_list_iterate_items_safe(pd, pd2, &pp->arg_create) {
/* Using existing orphan PVs is covered above. */
if (pp->preserve_existing && pd->is_orphan_pv)
continue;
if (!dm_list_empty(&pp->arg_fail) && must_use_all)
break;
if (!(pvl = dm_pool_alloc(cmd->mem, sizeof(*pvl)))) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("alloc pvl failed.");
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
coverity: missing error path
2016-03-01 13:40:53 +03:00
continue;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
pv_name = pd->name;
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_debug("Creating a new PV on %s.", pv_name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
redefine pvcreate structs New pv_create_args struct contains all the specific parameters for creating a PV, independent of the command.
2016-02-19 00:31:27 +03:00
if (!(pv = pv_create(cmd, pd->dev, &pp->pva))) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("Failed to setup physical volume \"%s\".", pv_name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
continue;
}
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
/* allow deviceidtype_ARG/deviceid_ARG ? */
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
memcpy(pvid, &pv->id.uuid, ID_LEN);
lvmdevices: use deviceidtype option strictly Only use the device id type specified by --deviceidtype, and fail if that type is not available for the device.
2022-09-15 17:45:21 +03:00
device_id_add(cmd, pd->dev, pvid, NULL, NULL, 0);
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
log_verbose("Set up physical volume for \"%s\" with %" PRIu64
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
" available sectors.", pv_name, pv_size(pv));
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
if (!label_remove(pv->dev)) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("Failed to wipe existing label on %s.", pv_name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
continue;
}
if (pp->zero) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_verbose("Zeroing start of device %s.", pv_name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
bcache: use wrappers for bcache read write in lvm Using a wrapper makes it easier to disable bcache if needed.
2018-02-27 20:26:04 +03:00
if (!dev_write_zeros(pv->dev, 0, 2048)) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("%s not wiped: aborting.", pv_name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
continue;
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_verbose("Writing physical volume data to disk \"%s\".", pv_name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
if (!pv_write(cmd, pv, 0)) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("Failed to write physical volume \"%s\".", pv_name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
pvcreate: fix error from pv_write After a pv_write() failure, the PV wasn't being skipped.
2016-02-26 01:38:59 +03:00
continue;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
}
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_print_unless_silent("Physical volume \"%s\" successfully created.",
pv_name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pvl->pv = pv;
dm_list_add(&pp->pvs, &pvl->list);
}
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
/*
* Remove PVs from devices for pvremove.
*/
dm_list_iterate_items_safe(pd, pd2, &pp->arg_remove) {
if (!label_remove(pd->dev)) {
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_error("Failed to wipe existing label(s) on %s.", pd->name);
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
dm_list_move(&pp->arg_fail, &pd->list);
continue;
}
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
device_id_pvremove(cmd, pd->dev);
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_print_unless_silent("Labels on physical volume \"%s\" successfully wiped.",
pvremove: use common toollib processing code Use the new pvcreate_each_device() function from toollib.
2016-02-17 00:00:50 +03:00
pd->name);
}
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
/*
* Special case: pvremove duplicate PVs (also see above).
*/
dm_list_iterate_items_safe(pd, pd2, &remove_duplicates) {
if (!label_remove(pd->dev)) {
log_error("Failed to wipe existing label(s) on %s.", pd->name);
dm_list_move(&pp->arg_fail, &pd->list);
continue;
}
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
lvmcache_del_dev_from_duplicates(pd->dev);
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
device_id_pvremove(cmd, pd->dev);
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
log_print_unless_silent("Labels on physical volume \"%s\" successfully wiped.",
pd->name);
}
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
/* TODO: when vgcreate uses only existing PVs this doesn't change and can be skipped */
debug: more tracing Check result of device_ids_write() and at least provide stack;
2021-03-10 03:26:30 +03:00
if (!device_ids_write(cmd))
stack;
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
vgcreate: close exclusive fd after pvcreate When vgcreate does an automatic pvcreate, it opens the dev with O_EXCL to ensure no other subsystem is using the device. This exclusive fd remained in bcache and prevented activation parts of lvm from using the dev. This appeared with vgcreate of a sanlock VG because of the unique combination where the dev is not yet a PV, so pvcreate is needed, and the vgcreate also creates and activates an internal LV for sanlock. Fix this by closing the exclusive fd after it's used by pvcreate so that it won't interfere with other bits of lvm that may try to use the device.
2018-08-01 18:26:28 +03:00
/*
* Don't keep devs open excl in bcache because the excl will prevent
* using that dev elsewhere.
*/
dm_list_iterate_items(devl, &rescan_devs)
label_scan_invalidate(devl->dev);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
dm_list_iterate_items(pd, &pp->arg_fail)
cleanup: indent and dots
2016-03-01 13:41:09 +03:00
log_debug("%s: command failed for %s.",
cmd->command->name, pd->name);
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
if (!dm_list_empty(&pp->arg_fail))
debug: use just single label
2023-08-14 15:09:25 +03:00
goto_bad;
toollib: add two phase pv processing code This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
2016-02-16 23:15:24 +03:00
return 1;
bad:
return 0;
}
cleanup: refactor common code Refactor shared code from _get_rootvg_dev() between vgchange and vgimportdevices to get_rootvg_dev_uuid() in toollib.c
2024-05-27 16:56:53 +03:00
int get_rootvg_dev_uuid(struct cmd_context *cmd, char **dm_uuid_out)
{
char dm_uuid[DM_UUID_LEN];
struct stat info;
FILE *fme = NULL;
struct mntent *me;
int found = 0;
if (!(fme = setmntent("/etc/mtab", "r")))
return_0;
while ((me = getmntent(fme))) {
if ((me->mnt_dir[0] == '/') && (me->mnt_dir[1] == '\0')) {
found = 1;
break;
}
}
endmntent(fme);
if (!found)
return_0;
if (stat(me->mnt_dir, &info) < 0)
return_0;
if (!device_get_uuid(cmd, MAJOR(info.st_dev), MINOR(info.st_dev), dm_uuid, sizeof(dm_uuid)))
return_0;
log_debug("Found root dm_uuid %s", dm_uuid);
/* UUID_PREFIX = "LVM-" */
if (strncmp(dm_uuid, UUID_PREFIX, sizeof(UUID_PREFIX) - 1))
return_0;
if (strlen(dm_uuid) < sizeof(UUID_PREFIX) - 1 + ID_LEN)
return_0;
*dm_uuid_out = dm_pool_strdup(cmd->mem, dm_uuid);
return 1;
}
Copy Permalink