2001-09-25 16:49:28 +04:00
/*
2004-03-30 23:35:44 +04:00
* Copyright ( C ) 2001 - 2004 Sistina Software , Inc . All rights reserved .
2015-04-10 15:08:19 +03:00
* Copyright ( C ) 2004 - 2015 Red Hat , Inc . All rights reserved .
2001-09-25 16:49:28 +04:00
*
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
2007-08-21 00:55:30 +04:00
* of the GNU Lesser General Public License v .2 .1 .
2004-03-30 23:35:44 +04:00
*
2007-08-21 00:55:30 +04:00
* You should have received a copy of the GNU Lesser General Public License
2004-03-30 23:35:44 +04:00
* along with this program ; if not , write to the Free Software Foundation ,
2016-01-21 13:49:46 +03:00
* Inc . , 51 Franklin Street , Fifth Floor , Boston , MA 02110 - 1301 USA
2001-09-25 16:49:28 +04:00
*/
2002-04-24 22:20:51 +04:00
# ifndef _LVM_TOOLS_H
# define _LVM_TOOLS_H
2001-09-25 16:49:28 +04:00
2018-05-14 12:30:20 +03:00
# include "tools/tool.h"
2002-12-20 02:25:55 +03:00
2018-05-14 12:30:20 +03:00
# include "lib/log/lvm-logging.h"
2015-07-06 19:30:18 +03:00
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"
2013-03-05 20:48:29 +04:00
# include "lvm-version.h"
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"
2018-05-14 12:30:20 +03:00
# include "lib/display/display.h"
2001-09-25 16:49:28 +04:00
# include "errors.h"
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"
2002-11-18 17:04:08 +03:00
# include "toollib.h"
2018-05-14 12:30:20 +03:00
# include "lib/notify/lvmnotify.h"
2018-12-07 23:35:22 +03:00
# include "lib/label/hints.h"
2002-01-07 14:12:11 +03:00
2002-11-18 17:04:08 +03:00
# include <ctype.h>
2002-01-07 14:12:11 +03:00
# include <sys/types.h>
2001-09-25 16:49:28 +04:00
# define CMD_LEN 256
# define MAX_ARGS 64
2017-02-10 20:36:11 +03:00
/* define the enums for each unique ID in command defs in command-lines.in */
enum {
# define cmd(a, b) a ,
# include "cmds.h"
# undef cmd
} ;
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
/* define the enums for the values accepted by command line --options, foo_VAL */
enum {
# define val(a, b, c, d) a ,
# include "vals.h"
# undef val
} ;
/* define the enums for the command line --options, foo_ARG */
enum {
2017-01-07 01:56:59 +03:00
# define arg(a, b, c, d, e, f, g) a ,
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
# include "args.h"
# undef arg
} ;
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 */
2002-02-11 23:50:53 +03:00
# define xx(a, b...) int a(struct cmd_context *cmd, int argc, char **argv);
2001-09-25 16:49:28 +04:00
# include "commands.h"
# undef xx
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
/* define enums for LV properties, foo_LVP */
2001-09-25 16:49:28 +04:00
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
# define lvp(a, b, c) a ,
# include "lv_props.h"
# undef lvp
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
/* define enums for LV types, foo_LVT */
enum {
# define lvt(a, b, c) a ,
# include "lv_types.h"
# undef lvt
} ;
# include "command.h"
2017-02-10 20:36:11 +03:00
# include "command-count.h"
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
2010-11-11 20:29:05 +03:00
# define ARG_COUNTABLE 0x00000001 /* E.g. -vvvv */
# define ARG_GROUPABLE 0x00000002 /* E.g. --addtag */
2002-01-10 19:47:04 +03:00
2010-11-11 20:29:05 +03:00
struct arg_values {
2006-05-10 01:23:51 +04:00
unsigned count ;
2001-09-25 16:49:28 +04:00
char * value ;
2002-12-20 02:25:55 +03:00
int32_t i_value ;
uint32_t ui_value ;
2002-12-12 23:55:49 +03:00
int64_t i64_value ;
uint64_t ui64_value ;
2001-11-10 01:01:04 +03:00
sign_t sign ;
2010-11-30 14:53:31 +03:00
percent_type_t percent ;
2001-09-25 16:49:28 +04:00
} ;
2010-11-11 20:29:05 +03:00
struct arg_value_group_list {
struct dm_list list ;
2016-06-17 12:03:14 +03:00
uint32_t prio ;
2020-08-28 20:15:01 +03:00
struct arg_values arg_values [ ] ;
2010-11-11 20:29:05 +03:00
} ;
2010-10-25 15:20:54 +04:00
# define PERMITTED_READ_ONLY 0x00000002
2015-02-13 17:58:51 +03:00
/* Process all VGs if none specified on the command line. */
2014-10-02 01:58:00 +04:00
# define ALL_VGS_IS_DEFAULT 0x00000004
2014-10-02 01:58:23 +04:00
/* Process all devices with --all if none are specified on the command line. */
# define ENABLE_ALL_DEVS 0x00000008
2015-12-02 00:50:14 +03:00
/* Command may try to interpret a vgname arg as a uuid. */
# define ALLOW_UUID_AS_NAME 0x00000010
2015-03-05 23:00:44 +03:00
/* Command needs a shared lock on a VG; it only reads the VG. */
# define LOCKD_VG_SH 0x00000020
commands: add new NO_METADATA_PROCESSING flag to selected commands
When a command is flagged with NO_METADATA_PROCESSING flag, it means
such command does not process any metadata and hence it doens't require
lvmetad, lvmpolld and it can get away with no locking too. These are
mostly simple commands (like lvmconfig/dumpconfig, version, types,
segtypes and other builtin commands that do not process metadata
in any way).
At first, when lvm command is executed, create toolcontext without
initializing connections (lvmetad,lvmpolld) and without initializing
filters (which depend on connections init). Instead, delay this
initialization until we know we need this. That is, until the
lvm_run_command fn is called in which we know what the actual
command to run is and hence we can avoid any connection, filter
or locking initiliazation for commands that would not make use
of it anyway.
For all the other create_toolcontext calls, we keep the original
behaviour - the filters and connections are initialized together
with the toolcontext.
2015-07-30 11:48:28 +03:00
/* Command does not process any metadata. */
# define NO_METADATA_PROCESSING 0x00000040
2016-02-16 23:15:24 +03:00
/* Command must use all specified arg names and fail if all cannot be used. */
# define MUST_USE_ALL_ARGS 0x00000100
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
/* Command should process unused duplicate devices. */
# define ENABLE_DUPLICATE_DEVS 0x00000400
2016-06-03 17:56:48 +03:00
/* Command does not accept tags as args. */
# define DISALLOW_TAG_ARGS 0x00000800
2016-12-09 22:30:42 +03:00
/* Command may need to find VG name in an option value. */
# define GET_VGNAME_FROM_OPTIONS 0x00001000
2018-04-19 00:29:42 +03:00
/* The data read from disk by label scan can be used for vg_read. */
# define CAN_USE_ONE_SCAN 0x00002000
2018-12-07 23:35:22 +03:00
/* Command can use hints file */
# define ALLOW_HINTS 0x00004000
2019-06-21 21:37:11 +03:00
/* Command can access exported vg. */
# define ALLOW_EXPORTED 0x00008000
skip indexing devices used by LVs in more commands
expands commit d5a06f9a7df5a43b2e2311db62ff8d3011217d74
"pvscan: skip indexing devices used by LVs"
The dev cache index is expensive and slow, so limit it
to commands that are used to observe the state of lvm.
The index is only used to print warnings about incorrect
device use by active LVs, e.g. if an LV is using a
multipath component device instead of the multipath
device. Commands that continue to use the index and
print the warnings:
fullreport, lvmdiskscan, vgs, lvs, pvs,
vgdisplay, lvdisplay, pvdisplay,
vgscan, lvscan, pvscan (excluding --cache)
A couple other commands were borrowing the DEV_USED_FOR_LV
flag to just check if a device was actively in use by LVs.
These are converted to the new dev_is_used_by_active_lv().
2021-07-08 00:59:56 +03:00
/* Command checks and reports warning if devs used by LV are incorrect. */
# define CHECK_DEVS_USED 0x00010000
2021-07-27 23:28:34 +03:00
/* Command prints devices file entries that were not found. */
# define DEVICE_ID_NOT_FOUND 0x00020000
2018-04-19 00:29:42 +03:00
2001-09-25 16:49:28 +04:00
void usage ( const char * name ) ;
/* the argument verify/normalise functions */
2010-11-11 20:29:05 +03:00
int yes_no_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2012-06-27 15:48:31 +04:00
int activation_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2017-03-03 13:33:10 +03:00
int cachemetadataformat_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2016-04-25 14:39:30 +03:00
int cachemode_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2012-08-08 00:24:41 +04:00
int discards_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2014-10-22 23:02:29 +04:00
int mirrorlog_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2010-11-11 20:29:05 +03:00
int size_kb_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2017-03-02 21:53:01 +03:00
int ssize_kb_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2010-11-11 20:29:05 +03:00
int size_mb_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2017-03-02 21:53:01 +03:00
int ssize_mb_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
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 ) ;
2010-11-11 20:29:05 +03:00
int int_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2017-01-03 15:02:52 +03:00
int uint32_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2010-11-11 20:29:05 +03:00
int int_arg_with_sign ( struct cmd_context * cmd , struct arg_values * av ) ;
2017-03-11 00:22:13 +03:00
int int_arg_with_plus ( struct cmd_context * cmd , struct arg_values * av ) ;
2017-02-24 22:44:05 +03:00
int extents_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
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 ) ;
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 ) ;
2015-03-05 23:00:44 +03:00
int locktype_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
2010-11-11 20:29:05 +03:00
int readahead_arg ( struct cmd_context * cmd , struct arg_values * av ) ;
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 ) ;
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 ) ;
2019-10-30 00:08:43 +03:00
int repairtype_arg ( struct cmd_context * cmd __attribute__ ( ( unused ) ) , struct arg_values * av ) ;
2019-12-10 20:06:45 +03:00
int dumptype_arg ( struct cmd_context * cmd __attribute__ ( ( unused ) ) , struct arg_values * av ) ;
2001-09-25 16:49:28 +04:00
/* we use the enums to access the switches */
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 ) ;
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 , . . . ) ;
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 , . . . ) ;
2013-03-22 23:20:33 +04:00
const char * arg_long_option_name ( int a ) ;
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 ) ;
2006-04-19 19:33:07 +04:00
int arg_count_increment ( struct cmd_context * cmd , int a ) ;
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 ) ;
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 ) ;
2010-11-11 20:29:05 +03:00
2006-04-19 19:33:07 +04:00
const char * command_name ( struct cmd_context * cmd ) ;
2001-10-08 22:44:22 +04:00
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 ) ;
2009-06-01 18:43:27 +04:00
int lvconvert_poll ( struct cmd_context * cmd , struct logical_volume * lv , unsigned background ) ;
2003-05-06 16:20:11 +04:00
2011-07-08 23:42:11 +04:00
int mirror_remove_missing ( struct cmd_context * cmd ,
struct logical_volume * lv , int force ) ;
2012-06-27 16:59:34 +04:00
int vgchange_activate ( struct cmd_context * cmd , struct volume_group * vg ,
2021-11-03 20:03:29 +03:00
activation_change_t activate , int vg_complete_to_activate ) ;
2014-10-07 19:45:45 +04:00
2016-01-07 17:17:08 +03:00
int vgchange_background_polling ( struct cmd_context * cmd , struct volume_group * vg ) ;
2017-07-13 00:03:41 +03:00
int vgchange_locktype_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2017-07-13 21:26:10 +03:00
int vgchange_lock_start_stop_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2017-07-13 21:43:39 +03:00
int vgchange_systemid_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2017-07-13 00:03:41 +03:00
2017-03-07 21:08:23 +03:00
struct lv_prop * get_lv_prop ( int lvp_enum ) ;
struct lv_type * get_lv_type ( int lvt_enum ) ;
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
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 ) ;
2017-09-18 12:33:47 +03:00
int lvconvert_repair_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2016-11-18 00:38:52 +03:00
int lvconvert_replace_pv_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
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 ) ;
2016-12-20 00:38:03 +03:00
int lvconvert_start_poll_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2016-12-07 23:30:57 +03:00
int lvconvert_to_pool_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
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 ) ;
2016-12-07 23:30:57 +03:00
int lvconvert_to_thin_with_external_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
int lvconvert_swap_pool_metadata_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2017-02-17 20:45:13 +03:00
int lvconvert_to_pool_or_swap_metadata_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2016-12-07 23:30:57 +03:00
int lvconvert_merge_thin_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2018-08-27 22:53:09 +03:00
int lvconvert_split_cache_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2016-12-07 23:30:57 +03:00
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 ) ;
2016-12-09 23:39:57 +03:00
int lvconvert_merge_mirror_images_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2016-12-20 00:53:21 +03:00
int lvconvert_change_mirrorlog_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2017-02-07 20:52:13 +03:00
int lvconvert_change_region_size_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
2016-12-09 23:39:57 +03:00
int lvconvert_merge_cmd ( struct cmd_context * cmd , int argc , char * * argv ) ;
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 ) ;
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 ) ;
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 ) ;
2001-10-06 01:39:30 +04:00
# endif
