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
dev-dct-vg-copy-2
lvm2/tools/tools.h

242 lines
12 KiB
C
Raw Permalink Normal View History

lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
/*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* Copyright (C) 2001-2004 Sistina Software, Inc. All rights reserved.
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
* Copyright (C) 2004-2015 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
*/
Merge with text format branch. Lots of changes/very little testing so far => there'll be bugs! Use 'vgcreate -M text' to create a volume group with its metadata stored in text files. Text format metadata changes should be reasonably atomic, with a (basic) automatic recovery mechanism if the system crashes while a change is in progress. Add a metadata section to lvm.conf to specify multiple directories if you want (recommended) to keep multiple copies of the metadata (eg on different filesystems). e.g. metadata { dirs = ["/etc/lvm/metadata1","/usr/local/lvm/metadata2"] } Plenty of refinements still in the pipeline.
2002-04-24 22:20:51 +04:00
#ifndef _LVM_TOOLS_H
#define _LVM_TOOLS_H
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
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 "tools/tool.h"
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
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/log/lvm-logging.h"
include: Standardise around new tool.h.
2015-07-06 19:30:18 +03:00
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/activate/activate.h"
#include "lib/format_text/archiver.h"
#include "lib/cache/lvmcache.h"
#include "lib/locking/lvmlockd.h"
dumpconfig: add --type, --atversion and --validate arg lvm dumpconfig [--type {current|default|missing|new}] [--atversion] [--validate] This patch adds above-mentioned args to lvm dumpconfig and it maps them to creation and writing out a configuration tree of a specific type (see also previous commit): - current maps to CFG_TYPE_CURRENT - default maps to CFG_TYPE_DEFAULT - missing maps to CFG_TYPE_MISSING - new maps to CFG_TYPE_NEW If --type is not defined, dumpconfig defaults to "--type current" which is the original behaviour of dumpconfig before all these changes. The --validate option just validates current configuration tree (lvm.conf/--config) and it writes a simple status message: "LVM configuration valid" or "LVM configuration invalid"
2013-03-05 20:48:29 +04:00
#include "lvm-version.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/config/config.h"
#include "lib/config/defaults.h"
#include "lib/device/dev-cache.h"
#include "lib/device/device.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"
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/display/display.h"
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
#include "errors.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/metadata/metadata-exported.h"
#include "lib/locking/locking.h"
#include "lib/misc/lvm-exec.h"
#include "lib/misc/lvm-file.h"
#include "lib/misc/lvm-signal.h"
#include "lib/misc/lvm-string.h"
#include "lib/metadata/segtype.h"
#include "lib/datastruct/str_list.h"
#include "lib/commands/toolcontext.h"
Some new features.
2002-11-18 17:04:08 +03:00
#include "toollib.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/notify/lvmnotify.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"
o sync tool changes for backup stuff.
2002-01-07 14:12:11 +03:00
Some new features.
2002-11-18 17:04:08 +03:00
#include <ctype.h>
o sync tool changes for backup stuff.
2002-01-07 14:12:11 +03:00
#include <sys/types.h>
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
#define CMD_LEN 256
#define MAX_ARGS 64
command: refactor common code to command_enum.h Move shared code to command_enum.h and avoid duplicating code.
2024-04-28 18:59:42 +03:00
#include "command_enums.h"
lvactivate checkpoint commit
2001-09-25 16:49:28 +04: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
/* command functions */
Preparation for an LVM2 liblvm - pass cmd_context into each tool and link some globals that the tools need into that structure.
2002-02-11 23:50:53 +03:00
#define xx(a, b...) int a(struct cmd_context *cmd, int argc, char **argv);
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
#include "commands.h"
#undef xx
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
#define ARG_COUNTABLE 0x00000001 /* E.g. -vvvv */
#define ARG_GROUPABLE 0x00000002 /* E.g. --addtag */
args: add ARG_NONINTERACTIVE for cmds not supported in lvm shell Certain args can't be used in lvm shell ("interactive mode") because they are not supported there. Add ARG_NONINTERACTIVE flag to mark such args and error out if we're in interactive mode and at the same time we detect use of such argument. Currently, this is the case for --reportformat arg - we don't support changing the format per command in lvm shell. The whole shell is running under a reportformat chosen at shell's start.
2022-08-26 13:17:45 +03:00
#define ARG_NONINTERACTIVE 0x00000004 /* only for use in noninteractive mode */
cleanup: use ARG_LONG_OPT Just like with _VAL strings, also _ARG strings do not need to be present - as we can easily check for LONG opt version just by adding attribute. With attribute ARG_LONG_OPT string arg name[] becomes unused and can be safely removed. Also within _find_command_id_function() we do not need to handle 'command_enum == CMD_NONE' as separate case and just use single loop.
2024-05-18 02:38:18 +03:00
#define ARG_LONG_OPT 0x00000008 /* arg has long format option */
Separate constant fields from variable ones.
2002-01-10 19:47:04 +03:00
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
struct arg_values {
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
char *value;
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
int32_t i_value;
uint32_t ui_value;
New column-based reporting tools: lvs, pvs & vgs.
2002-12-12 23:55:49 +03:00
int64_t i64_value;
uint64_t ui64_value;
o Added lvextend o Full signed arguments to lvreduce/lvextend o Consistent lv_number/pe map use o Populate pv->pe_allocated o Fixes for allocation/writing of multiple LVs
2001-11-10 01:01:04 +03:00
sign_t sign;
Refactor the percent (mirror sync, snapshot usage) handling code to use fixed-point values instead of a combination of a float value and an enum.
2010-11-30 14:53:31 +03:00
percent_type_t percent;
debug: update some structure members Makes pahole output look slightly better.
2024-03-28 19:19:44 +03:00
uint16_t count;
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
};
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
struct arg_value_group_list {
struct dm_list list;
gcc: use uint16_t for counters
2024-03-27 03:03:08 +03:00
uint16_t prio;
gcc: zero-sized array to fexlible array C99 Switch remaining zero sized struct to flexible arrays to be C99 complient. These simple rules should apply: - The incomplete array type must be the last element within the structure. - There cannot be an array of structures that contain a flexible array member. - Structures that contain a flexible array member cannot be used as a member of another structure. - The structure must contain at least one named member in addition to the flexible array member. Although some of the code pieces should be still improved.
2020-08-28 20:15:01 +03:00
struct arg_values arg_values[];
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
};
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
void usage(const char *name);
cleanup: typos in comments Collection of typos in code comments. Should have no runtime effect.
2024-08-30 00:05:41 +03:00
/* the argument verify/normalize functions */
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
int yes_no_arg(struct cmd_context *cmd, struct arg_values *av);
args: add --activate synonym for --available arg We're refererring to 'activation' all over the code and we're talking about 'LVs being activated' all the time so let's use 'activation/activate' everywhere for clarity and consistency (still providing the old 'available' keyword as a synonym for backward compatibility with existing environments).
2012-06-27 15:48:31 +04:00
int activation_arg(struct cmd_context *cmd, struct arg_values *av);
cache: allow to specify cachemetadataformat OO_LVCREATE_CACHE accepts --cachemetadataformat. Support new option --cachemetadataformat auto|1|2 for caching. Word 'auto' can be also be given as '0'.
2017-03-03 13:33:10 +03:00
int cachemetadataformat_arg(struct cmd_context *cmd, struct arg_values *av);
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
int cachemode_arg(struct cmd_context *cmd, struct arg_values *av);
thin: use discards as plural rather than singular Global change from --discard to --discards, as that feels more natural.
2012-08-08 00:24:41 +04:00
int discards_arg(struct cmd_context *cmd, struct arg_values *av);
mirror: extra parsing for mirrorlog arg Put validation of mirrorlog arg into a separate function.
2014-10-22 23:02:29 +04:00
int mirrorlog_arg(struct cmd_context *cmd, struct arg_values *av);
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
int size_kb_arg(struct cmd_context *cmd, struct arg_values *av);
lvcreate/lvresize: the --size option accepts signed values There was confusion in the code about whether or not the --size option accepted a sign. Make it consistent and clear that it does. This exposes a new problem in that an option can only accept one value type, e.g. --size can only accept a signed number, it cannot accept a positive or negative number for some commands and reject negative numbers for others. In practice, lvcreate accepts only positive --size values and lvresize accepts positive or negative --size values. There is currently no way to encode this difference. Until that is fixed, the man page output is hacked to avoid printing the [+|-] prefix for sizes in lvcreate.
2017-03-02 21:53:01 +03:00
int ssize_kb_arg(struct cmd_context *cmd, struct arg_values *av);
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
int size_mb_arg(struct cmd_context *cmd, struct arg_values *av);
lvcreate/lvresize: the --size option accepts signed values There was confusion in the code about whether or not the --size option accepted a sign. Make it consistent and clear that it does. This exposes a new problem in that an option can only accept one value type, e.g. --size can only accept a signed number, it cannot accept a positive or negative number for some commands and reject negative numbers for others. In practice, lvcreate accepts only positive --size values and lvresize accepts positive or negative --size values. There is currently no way to encode this difference. Until that is fixed, the man page output is hacked to avoid printing the [+|-] prefix for sizes in lvcreate.
2017-03-02 21:53:01 +03:00
int ssize_mb_arg(struct cmd_context *cmd, struct arg_values *av);
commands: clean up and unify signed option value handling Add new values for different sign variations, resulting in: size_VAL no sign accepted ssize_VAL accepts + or - psize_VAL accepts + nsize_VAL accpets - extents_VAL no sign accepted sextents_VAL accepts + or - pextents_VAL accepts + nextents_VAL accepts - Depending on the command being run, change the option values for --size, --extents, --poolmetadatasize to use the appropriate value from above. lvcreate uses no sign (but accepts + and ignores it). lvresize accepts +|- for a relative change. lvextend accepts + for a relative change. lvreduce accepts - for a relative change.
2017-03-08 01:55:07 +03:00
int psize_mb_arg(struct cmd_context *cmd, struct arg_values *av);
int nsize_mb_arg(struct cmd_context *cmd, struct arg_values *av);
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
int int_arg(struct cmd_context *cmd, struct arg_values *av);
lvmcmdline: support uint32 Add simple function to wrap usage for only uint32 numbers. Unlike 'int_arg' which accepts full range of 64bit number this function will error on numbers out of this range: <0, UINT32_MAX>
2017-01-03 15:02:52 +03:00
int uint32_arg(struct cmd_context *cmd, struct arg_values *av);
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
int int_arg_with_sign(struct cmd_context *cmd, struct arg_values *av);
commands: use correct relative signs with mirror option As was recently done with relative signes for sizes/extents, limit the signs used with the mirrors option, e.g. lvcreate --mirrors now does not accept or advertise an optional minus sign with the value. lvconvert --mirrors accepts +|-.
2017-03-11 00:22:13 +03:00
int int_arg_with_plus(struct cmd_context *cmd, struct arg_values *av);
man: use Size variable for a number with unit Define a separate variable type Size to represent a number that takes an optional UNIT.
2017-02-24 22:44:05 +03:00
int extents_arg(struct cmd_context *cmd, struct arg_values *av);
commands: clean up and unify signed option value handling Add new values for different sign variations, resulting in: size_VAL no sign accepted ssize_VAL accepts + or - psize_VAL accepts + nsize_VAL accpets - extents_VAL no sign accepted sextents_VAL accepts + or - pextents_VAL accepts + nextents_VAL accepts - Depending on the command being run, change the option values for --size, --extents, --poolmetadatasize to use the appropriate value from above. lvcreate uses no sign (but accepts + and ignores it). lvresize accepts +|- for a relative change. lvextend accepts + for a relative change. lvreduce accepts - for a relative change.
2017-03-08 01:55:07 +03:00
int sextents_arg(struct cmd_context *cmd, struct arg_values *av);
int pextents_arg(struct cmd_context *cmd, struct arg_values *av);
int nextents_arg(struct cmd_context *cmd, struct arg_values *av);
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
int major_arg(struct cmd_context *cmd, struct arg_values *av);
int minor_arg(struct cmd_context *cmd, struct arg_values *av);
int string_arg(struct cmd_context *cmd, struct arg_values *av);
int tag_arg(struct cmd_context *cmd, struct arg_values *av);
int permission_arg(struct cmd_context *cmd, struct arg_values *av);
int metadatatype_arg(struct cmd_context *cmd, struct arg_values *av);
int units_arg(struct cmd_context *cmd, struct arg_values *av);
int segtype_arg(struct cmd_context *cmd, struct arg_values *av);
int alloc_arg(struct cmd_context *cmd, struct arg_values *av);
Add lvmlockd
2015-03-05 23:00:44 +03:00
int locktype_arg(struct cmd_context *cmd, struct arg_values *av);
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
int readahead_arg(struct cmd_context *cmd, struct arg_values *av);
cleanup: add _mb_ to regiosize option Just like with others mentions default unit in function name.
2018-04-18 13:56:32 +03:00
int regionsize_mb_arg(struct cmd_context *cmd, struct arg_values *av);
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 vgmetadatacopies_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
int pvmetadatacopies_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
int metadatacopies_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
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 polloperation_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
int writemostly_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
int syncaction_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
int reportformat_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
int configreport_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
int configtype_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
pvck: repair headers and metadata To write a new/repaired pv_header and label_header: pvck --repairtype pv_header --file <file> <device> This uses the metadata input file to find the PV UUID, device size, and data offset. To write new/repaired metadata text and mda_header: pvck --repairtype metadata --file <file> <device> This requires a good pv_header which points to one or two metadata areas. Any metadata areas referenced by the pv_header are updated with the specified metadata and a new mda_header. "--settings mda_num=1|2" can be used to select one mda to repair. To combine all header and metadata repairs: pvck --repair --file <file> <device> It's best to use a raw metadata file as input, that was extracted from another PV in the same VG (or from another metadata area on the same PV.) pvck will also accept a metadata backup file, but that will produce metadata that is not identical to other metadata copies on other PVs and other areas. So, when using a backup file, consider using it to update metadata on all PVs/areas. To get a raw metadata file to use for the repair, see pvck --dump metadata|metadata_search. List all instances of metadata from the metadata area: pvck --dump metadata_search <device> Save one instance of metadata at the given offset to the specified file (this file can be used for repair): pvck --dump metadata_search --file <file> --settings "metadata_offset=<off>" <device>
2019-10-30 00:08:43 +03:00
int repairtype_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
pvck: show specific dump option values
2019-12-10 20:06:45 +03:00
int dumptype_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
report: support printing full column names in report headings Reuse existing report/headings config setting to make it possible to change the type of headings to display: 0 - no headings 1 - column name abbreviations (default and original functionality) 2 - full column names (column names are equal to exact names that -o|--options also accepts to set report output) Also, add '--headings none|abbrev|full|0|1|2' command line option so we are able to select the heading type for each LVM reporting command directly.
2023-08-22 11:54:35 +03:00
int headings_arg(struct cmd_context *cmd __attribute__((unused)), struct arg_values *av);
lvactivate checkpoint commit
2001-09-25 16:49:28 +04:00
/* we use the enums to access the switches */
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
int arg_is_valid_for_command(const struct cmd_context *cmd, int a);
Tidy some uses of arg_count and introduce arg_is_set.
2009-11-03 18:50:42 +03:00
unsigned arg_count(const struct cmd_context *cmd, int a);
unsigned arg_is_set(const struct cmd_context *cmd, int a);
tools: switch logic for new arg_ func Revert logic and rename new arg_ functions to: arg_from_list_is_set() arg_outside_list_is_set() When err_found is given, log_error message is automaticaly printed.
2014-07-18 23:56:37 +04:00
int arg_from_list_is_set(const struct cmd_context *cmd, const char *err_found, ...);
int arg_outside_list_is_set(const struct cmd_context *cmd, const char *err_found, ...);
toollib: new arg list functions Check for negative arg list: arg_from_list_is_negative() Check for zero arg in list: arg_from_list_is_zero()
2014-10-15 17:06:42 +04:00
int arg_from_list_is_negative(const struct cmd_context *cmd, const char *err_found, ...);
int arg_from_list_is_zero(const struct cmd_context *cmd, const char *err_found, ...);
cmdline: add arg_long_option_name Add simple function to return long_name string option for given arg.
2013-03-22 23:20:33 +04:00
const char *arg_long_option_name(int a);
cleanup: use const for cmd context
2014-09-19 16:29:12 +04:00
const char *arg_value(const struct cmd_context *cmd, int a);
const char *arg_str_value(const struct cmd_context *cmd, int a, const char *def);
int32_t arg_int_value(const struct cmd_context *cmd, int a, const int32_t def);
int32_t first_grouped_arg_int_value(const struct cmd_context *cmd, int a, const int32_t def);
uint32_t arg_uint_value(const struct cmd_context *cmd, int a, const uint32_t def);
int64_t arg_int64_value(const struct cmd_context *cmd, int a, const int64_t def);
uint64_t arg_uint64_value(const struct cmd_context *cmd, int a, const uint64_t def);
const void *arg_ptr_value(const struct cmd_context *cmd, int a, const void *def);
sign_t arg_sign_value(const struct cmd_context *cmd, int a, const sign_t def);
percent_type_t arg_percent_value(const struct cmd_context *cmd, int a, const percent_type_t def);
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
int arg_count_increment(struct cmd_context *cmd, int a);
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +03:00
unsigned grouped_arg_count(const struct arg_values *av, int a);
unsigned grouped_arg_is_set(const struct arg_values *av, int a);
const char *grouped_arg_str_value(const struct arg_values *av, int a, const char *def);
Switch pvscan --cache major:minor to --major --minor.
2012-03-06 06:30:49 +04:00
int32_t grouped_arg_int_value(const struct arg_values *av, int a, const int32_t def);
Support repetition of --addtag and --deltag arguments. Add infrastructure for specific cmdline arguments to be repeated in groups. Split the_args cmdline arguments and values into arg_props and arg_values.
2010-11-11 20:29:05 +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);
vgrename & vgck
2001-10-08 22:44:22 +04:00
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
int pvmove_poll(struct cmd_context *cmd, const char *pv_name, const char *uuid,
const char *vg_name, const char *lv_name, unsigned background);
Fix convert polling to ignore LV with different UUID. When mirror convert polling is started (mainly as backgound process, in lvchange -a y or in lvconvert itself) it tries to read VG and LV identified by its name. Unfortunatelly, the VG can have already different LV under the same name, and various more or less funny things can happen (note that _finish_lvconvert_mirror suspends the volume for example). (the typical example is our testing script which continuously recreates LVs under the same name in the same VG.) This patch adds optional uuid parameter which helps to properly select the monitoring object. For lvconvert polling it is set to LV UUID and both _get_lvconvert_vg and _get_lvconvert_lv uses it to read proper VG/LV. (In the pvmove case it is NULL, here we poll for physical volume name).
2009-06-01 18:43:27 +04:00
int lvconvert_poll(struct cmd_context *cmd, struct logical_volume *lv, unsigned background);
remove global pvmove lock & poll for completion
2003-05-06 16:20:11 +04:00
remove unnecessary lvconvert.h
2011-07-08 23:42:11 +04:00
int mirror_remove_missing(struct cmd_context *cmd,
struct logical_volume *lv, int force);
activate: add autoactivation hooks Define an 'activation_handler' that gets called automatically on PV appearance/disappearance while processing the lvmetad_pv_found and lvmetad_pv_gone functions that are supposed to update the lvmetad state based on PV availability state. For now, the actual support is for PV appearance only, leaving room for PV disappearance support as well (which is a more complex problem to solve as this needs to count with possible device stack). Add a new activation change mode - CHANGE_AAY exposed as '--activate ay/-aay' argument ('activate automatically'). Factor out the vgchange activation functionality for use in other tools (like pvscan...).
2012-06-27 16:59:34 +04:00
int vgchange_activate(struct cmd_context *cmd, struct volume_group *vg,
Allow system.devices to be automatically created on first boot An OS installer can create system.devices for the system and disks, but an OS image cannot create the system-specific system.devices. The OS image can instead configure the image so that lvm will create system.devices on first boot. Image preparation steps to enable auto creation of system.devices: - create empty file /etc/lvm/devices/auto-import-rootvg - remove any existing /etc/lvm/devices/system.devices - enable lvm-devices-import.path - enable lvm-devices-import.service On first boot of the prepared image: - udev triggers vgchange -aay --autoactivation event <rootvg> - vgchange activates LVs in the root VG - vgchange finds the file /etc/lvm/devices/auto-import-rootvg, and no /etc/lvm/devices/system.devices, so it creates /run/lvm/lvm-devices-import - lvm-devices-import.path is run when /run/lvm/lvm-devices-import appears, and triggers lvm-devices-import.service - lvm-devices-import.service runs vgimportdevices --rootvg --auto - vgimportdevices finds /etc/lvm/devices/auto-import-rootvg, and no system.devices, so it creates system.devices containing PVs in the root VG, and removes /etc/lvm/devices/auto-import-rootvg and /run/lvm/lvm-devices-import Run directly, vgimportdevices --rootvg (without --auto), will create a new system.devices for the root VG, or will add devices for the root VG to an existing system.devices.
2024-04-24 01:08:26 +03:00
activation_change_t activate, int vg_complete_to_activate, char *root_dm_uuid);
vgremove: Use process_each_lv_in_vg.
2014-10-07 19:45:45 +04:00
pvscan: restore polling in autoactivation handler This commit fixes regression in auto-activation code introduced in commit: c26d81d6e6939906729d91fae83cd8bbdd743bb7. - resolves rhbz1295562
2016-01-07 17:17:08 +03:00
int vgchange_background_polling(struct cmd_context *cmd, struct volume_group *vg);
vgchange: separate change locktype and allow recovery Add an independent command definition for "vgchange --locktype", and split the implementation out of the set of common metadata changes. It is unlike normal metadata changes, and can only be run by itself. (Changing the lock type is similar in principle to changing the VG name or the VG system ID; it effects the ability of any host to see or access the VG.) At some point this command lost the ability to forcibly change the lock type of a shared VG to "none" (making it a local VG). This can be necessary to repair shared VGs (e.g. recovery steps that occur in vg_read are disabled for shared VGs because they are not locked properly, or recovering sanlock locks when the PV holding them is lost.) "vgchange --locktype none --lockopt force VG" is used as the method of forcing the shared VG to become local so that it can be repaired.
2017-07-13 00:03:41 +03:00
int vgchange_locktype_cmd(struct cmd_context *cmd, int argc, char **argv);
vgchange: split out code for lockstart and lockstop Use the command definitions to separate the implementation of lockstop and lockstart from the rest of vgchange.
2017-07-13 21:26:10 +03:00
int vgchange_lock_start_stop_cmd(struct cmd_context *cmd, int argc, char **argv);
vgchange: split out code for systemid Use the command definitions to separate the implementation of vgchange systemid from the rest of vgchange.
2017-07-13 21:43:39 +03:00
int vgchange_systemid_cmd(struct cmd_context *cmd, int argc, char **argv);
vgchange: separate change locktype and allow recovery Add an independent command definition for "vgchange --locktype", and split the implementation out of the set of common metadata changes. It is unlike normal metadata changes, and can only be run by itself. (Changing the lock type is similar in principle to changing the VG name or the VG system ID; it effects the ability of any host to see or access the VG.) At some point this command lost the ability to forcibly change the lock type of a shared VG to "none" (making it a local VG). This can be necessary to repair shared VGs (e.g. recovery steps that occur in vg_read are disabled for shared VGs because they are not locked properly, or recovering sanlock locks when the PV holding them is lost.) "vgchange --locktype none --lockopt force VG" is used as the method of forcing the shared VG to become local so that it can be repaired.
2017-07-13 00:03:41 +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 opt_name *get_opt_name(int opt);
const struct val_name *get_val_name(int val);
const struct lv_prop *get_lv_prop(int lvp_enum);
const struct lv_type *get_lv_type(int lvt_enum);
lvconvert: use command defs for thin/cache/pool creation Everything related to thin and cache.
2016-12-07 23:30:57 +03:00
struct command *get_command(int cmd_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
lvchange: make use of command definitions Reorganize the lvchange code to take advantage of the command definition, and remove the validation that is done by the command definintion rules.
2016-11-17 01:05:47 +03:00
int lvchange_properties_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvchange_activate_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvchange_refresh_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvchange_resync_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvchange_syncaction_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvchange_rebuild_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvchange_monitor_poll_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvchange_persistent_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: support repair of cache/cachepool Extend repair for cache and cachepool target and user 'lvconvert_repair' routine name.
2017-09-18 12:33:47 +03:00
int lvconvert_repair_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: repair and replace: use command definitions This lifts the lvconvert --repair and --replace commands out of the monolithic lvconvert implementation. The previous calls into repair/replace can no longer be reached and will be removed in a separate commit.
2016-11-18 00:38:52 +03:00
int lvconvert_replace_pv_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: snapshot: use command definitions Lift all the snapshot utilities (merge, split, combine) out of the monolithic lvconvert implementation, using the command definitions. The old code associated with these commands is now unused and will be removed separately.
2016-11-18 22:16:04 +03:00
int lvconvert_merge_snapshot_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvconvert_split_snapshot_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvconvert_combine_split_snapshot_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: add startpoll command using command def This is a new explicit version of 'lvconvert LV' which has been an obscure way of triggering polling to be restarted on an LV that was previously converted.
2016-12-20 00:38:03 +03:00
int lvconvert_start_poll_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: use command defs for thin/cache/pool creation Everything related to thin and cache.
2016-12-07 23:30:57 +03:00
int lvconvert_to_pool_cmd(struct cmd_context *cmd, int argc, char **argv);
Use "cachevol" to refer to cache on a single LV and "cachepool" to refer to a cache on a cache pool object. The problem was that the --cachepool option was being used to refer to both a cache pool object, and to a standard LV used for caching. This could be somewhat confusing, and it made it less clear when each kind would be used. By separating them, it's clear when a cachepool or a cachevol should be used. Previously: - lvm would use the cache pool approach when the user passed a cache-pool LV to the --cachepool option. - lvm would use the cache vol approach when the user passed a standard LV in the --cachepool option. Now: - lvm will always use the cache pool approach when the user uses the --cachepool option. - lvm will always use the cache vol approach when the user uses the --cachevol option.
2019-01-30 18:55:34 +03:00
int lvconvert_to_cache_with_cachevol_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvconvert_to_cache_with_cachepool_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvconvert_to_writecache_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: use command defs for thin/cache/pool creation Everything related to thin and cache.
2016-12-07 23:30:57 +03:00
int lvconvert_to_thin_with_external_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: support conversion to thin volume Update pool conversion function to handle also conversion of thick LV to thin LV by moving thick LV into thin pool data LV and creating fully provissioned thin LV on top of this volume. Reworking existing conversion to use insert_layer_for_lv co the uuid is now kept with thin-pool - this should however not really matter as we are doing full deactivation & activation cycle. With conversion to thin LV user can use same set of arguments to set chunk-size. TODO: add some smart code to decide best values for chunks sizes.
2023-07-04 22:34:47 +03:00
int lvconvert_to_thin_with_data_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: use command defs for thin/cache/pool creation Everything related to thin and cache.
2016-12-07 23:30:57 +03:00
int lvconvert_swap_pool_metadata_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: include swap behavior in generic pool syntax For this syntax: lvconvert --thinpool LV1 --poolmetadata LV2 lvconvert --cachepool LV1 --poolmetadata LV2 Restore the metadata swapping behavior in addition to the pool creation behavior. When LV1 is already a pool, the metadata LV will be swapped with LV2. When LV1 is not a pool, it will be converted to a pool using the specified LV for metadata. This syntax is no longer advertised because of the ambiguous behavior. The primary syntaxes for pool creation and metadata swapping will be the advertised methods.
2017-02-17 20:45:13 +03:00
int lvconvert_to_pool_or_swap_metadata_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: use command defs for thin/cache/pool creation Everything related to thin and cache.
2016-12-07 23:30:57 +03:00
int lvconvert_merge_thin_cmd(struct cmd_context *cmd, int argc, char **argv);
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
int lvconvert_split_cache_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: use command defs for thin/cache/pool creation Everything related to thin and cache.
2016-12-07 23:30:57 +03:00
lvconvert: use command defs for raid/mirror types All lvconvert functionality has been moved out of the previous monolithic lvconvert code, except conversions related to raid/mirror/striped/linear. This switches that remaining code to be based on command defs, and standard process_each_lv arg processing. This final switch results in quite a bit of dead code that is also removed.
2016-12-20 00:53:21 +03:00
int lvconvert_raid_types_cmd(struct cmd_context * cmd, int argc, char **argv);
int lvconvert_split_mirror_images_cmd(struct cmd_context * cmd, int argc, char **argv);
lvconvert: use command defs for mergemirrors and route the generic --merge to one of the specific merge functions
2016-12-09 23:39:57 +03:00
int lvconvert_merge_mirror_images_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: use command defs for raid/mirror types All lvconvert functionality has been moved out of the previous monolithic lvconvert code, except conversions related to raid/mirror/striped/linear. This switches that remaining code to be based on command defs, and standard process_each_lv arg processing. This final switch results in quite a bit of dead code that is also removed.
2016-12-20 00:53:21 +03:00
int lvconvert_change_mirrorlog_cmd(struct cmd_context * cmd, int argc, char **argv);
lvconvert: add command to change region size of a raid LV
2017-02-07 20:52:13 +03:00
int lvconvert_change_region_size_cmd(struct cmd_context * cmd, int argc, char **argv);
lvconvert: use command defs for mergemirrors and route the generic --merge to one of the specific merge functions
2016-12-09 23:39:57 +03:00
int lvconvert_merge_cmd(struct cmd_context *cmd, int argc, char **argv);
lvconvert: support to convert lv into vdopool Support: lvconvert --type vdo-pool vg/lv lvconvert --vdopool vg/lv --virtualsize 10G
2018-07-01 00:38:49 +03:00
int lvconvert_to_vdopool_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvconvert_to_vdopool_param_cmd(struct cmd_context *cmd, int argc, char **argv);
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 lvconvert_integrity_cmd(struct cmd_context *cmd, int argc, char **argv);
lvcreate: new cache or writecache lv with single command To create a new cache or writecache LV with a single command: lvcreate --type cache|writecache -n Name -L Size --cachedevice PVfast VG [PVslow ...] - A new main linear|striped LV is created as usual, using the specified -n Name and -L Size, and using the optionally specified PVslow devices. - Then, a new cachevol LV is created internally, using PVfast specified by the cachedevice option. - Then, the cachevol is attached to the main LV, converting the main LV to type cache|writecache. Include --cachesize Size to specify the size of cache|writecache to create from the specified --cachedevice PVs, otherwise the entire cachedevice PV is used. The --cachedevice option can be repeated to create the cache from multiple devices, or the cachedevice option can contain a tag name specifying a set of PVs to allocate the cache from. To create a new cache or writecache LV with a single command using an existing cachevol LV: lvcreate --type cache|writecache -n Name -L Size --cachevol LVfast VG [PVslow ...] - A new main linear|striped LV is created as usual, using the specified -n Name and -L Size, and using the optionally specified PVslow devices. - Then, the cachevol LVfast is attached to the main LV, converting the main LV to type cache|writecache. In cases where more advanced types (for the main LV or cachevol LV) are needed, they should be created independently and then combined with lvconvert. Example ------- user creates a new VG with one slow device and one fast device: $ vgcreate vg /dev/slow1 /dev/fast1 user creates a new 8G main LV on /dev/slow1 that uses all of /dev/fast1 as a writecache: $ lvcreate --type writecache --cachedevice /dev/fast1 -n main -L 8G vg /dev/slow1 Example ------- user creates a new VG with two slow devs and two fast devs: $ vgcreate vg /dev/slow1 /dev/slow2 /dev/fast1 /dev/fast2 user creates a new 8G main LV on /dev/slow1 and /dev/slow2 that uses all of /dev/fast1 and /dev/fast2 as a writecache: $ lvcreate --type writecache --cachedevice /dev/fast1 --cachedevice /dev/fast2 -n main -L 8G vg /dev/slow1 /dev/slow2 Example ------- A user has several slow devices and several fast devices in their VG, the slow devs have tag @slow, the fast devs have tag @fast. user creates a new 8G main LV on the slow devs with a 2G writecache on the fast devs: $ lvcreate --type writecache -n main -L 8G --cachedevice @fast --cachesize 2G vg @slow
2020-04-10 21:17:37 +03:00
int lvcreate_and_attach_writecache_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvcreate_and_attach_cache_cmd(struct cmd_context *cmd, int argc, char **argv);
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
int pvscan_display_cmd(struct cmd_context *cmd, int argc, char **argv);
int pvscan_cache_cmd(struct cmd_context *cmd, int argc, char **argv);
lvcreate: new cache or writecache lv with single command To create a new cache or writecache LV with a single command: lvcreate --type cache|writecache -n Name -L Size --cachedevice PVfast VG [PVslow ...] - A new main linear|striped LV is created as usual, using the specified -n Name and -L Size, and using the optionally specified PVslow devices. - Then, a new cachevol LV is created internally, using PVfast specified by the cachedevice option. - Then, the cachevol is attached to the main LV, converting the main LV to type cache|writecache. Include --cachesize Size to specify the size of cache|writecache to create from the specified --cachedevice PVs, otherwise the entire cachedevice PV is used. The --cachedevice option can be repeated to create the cache from multiple devices, or the cachedevice option can contain a tag name specifying a set of PVs to allocate the cache from. To create a new cache or writecache LV with a single command using an existing cachevol LV: lvcreate --type cache|writecache -n Name -L Size --cachevol LVfast VG [PVslow ...] - A new main linear|striped LV is created as usual, using the specified -n Name and -L Size, and using the optionally specified PVslow devices. - Then, the cachevol LVfast is attached to the main LV, converting the main LV to type cache|writecache. In cases where more advanced types (for the main LV or cachevol LV) are needed, they should be created independently and then combined with lvconvert. Example ------- user creates a new VG with one slow device and one fast device: $ vgcreate vg /dev/slow1 /dev/fast1 user creates a new 8G main LV on /dev/slow1 that uses all of /dev/fast1 as a writecache: $ lvcreate --type writecache --cachedevice /dev/fast1 -n main -L 8G vg /dev/slow1 Example ------- user creates a new VG with two slow devs and two fast devs: $ vgcreate vg /dev/slow1 /dev/slow2 /dev/fast1 /dev/fast2 user creates a new 8G main LV on /dev/slow1 and /dev/slow2 that uses all of /dev/fast1 and /dev/fast2 as a writecache: $ lvcreate --type writecache --cachedevice /dev/fast1 --cachedevice /dev/fast2 -n main -L 8G vg /dev/slow1 /dev/slow2 Example ------- A user has several slow devices and several fast devices in their VG, the slow devs have tag @slow, the fast devs have tag @fast. user creates a new 8G main LV on the slow devs with a 2G writecache on the fast devs: $ lvcreate --type writecache -n main -L 8G --cachedevice @fast --cachesize 2G vg @slow
2020-04-10 21:17:37 +03:00
int lvconvert_writecache_attach_single(struct cmd_context *cmd,
struct logical_volume *lv,
struct processing_handle *handle);
int lvconvert_cachevol_attach_single(struct cmd_context *cmd,
struct logical_volume *lv,
struct processing_handle *handle);
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
int lvresize_cmd(struct cmd_context *cmd, int argc, char **argv);
int lvextend_policy_cmd(struct cmd_context *cmd, int argc, char **argv);
Sync include file changes.
2001-10-06 01:39:30 +04:00
#endif
Copy Permalink