2002-02-11 23:50:53 +03:00
/*
2004-03-30 23:35:44 +04:00
* Copyright ( C ) 2001 - 2004 Sistina Software , Inc . All rights reserved .
2009-02-23 00:14:37 +03:00
* Copyright ( C ) 2004 - 2009 Red Hat , Inc . All rights reserved .
2002-02-11 23:50:53 +03:00
*
2004-03-30 23:35:44 +04:00
* This file is part of LVM2 .
2002-02-11 23:50:53 +03:00
*
2004-03-30 23:35:44 +04:00
* This copyrighted material is made available to anyone wishing to use ,
* modify , copy , or redistribute it subject to the terms and conditions
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
2002-02-11 23:50:53 +03:00
*/
# ifndef _LVM_TOOLCONTEXT_H
# define _LVM_TOOLCONTEXT_H
2018-05-14 12:30:20 +03:00
# include "lib/device/dev-cache.h"
# include "lib/device/dev-type.h"
2002-02-11 23:50:53 +03:00
2002-11-18 17:01:16 +03:00
# include <limits.h>
/*
* Config options that can be changed while commands are processed
*/
struct config_info {
int debug ;
2013-01-08 02:25:19 +04:00
int debug_classes ;
2002-11-18 17:01:16 +03:00
int verbose ;
config: add silent mode
Accept -q as the short form of --quiet.
Suppress non-essential standard output if -q is given twice.
Treat log/silent in lvm.conf as equivalent to -qq.
Review all log_print messages and change some to
log_print_unless_silent.
When silent, the following commands still produce output:
dumpconfig, lvdisplay, lvmdiskscan, lvs, pvck, pvdisplay,
pvs, version, vgcfgrestore -l, vgdisplay, vgs.
[Needs checking.]
Non-essential messages are shifted from log level 4 to log level 5
for syslog and lvm2_log_fn purposes.
2012-08-25 23:35:48 +04:00
int silent ;
pvscan: add options listlvs listvg checkcomplete
pvscan --cache <dev>
. read only dev
. create online file for dev
pvscan --listvg <dev>
. read only dev
. list VG using dev
pvscan --listlvs <dev>
. read only dev
. list VG using dev
. list LVs using dev
pvscan --cache --listvg [--checkcomplete] <dev>
. read only dev
. create online file for dev
. list VG using dev
. [check online files and report if VG is complete]
pvscan --cache --listlvs [--checkcomplete] <dev>
. read only dev
. create online file for dev
. list VG using dev
. list LVs using dev
. [check online files and report if VG is complete]
. [check online files and report if LVs are complete]
[--vgonline]
can be used with --checkcomplete, to enable use of a vg online
file. This results in only the first pvscan command to see
the complete VG to report 'VG complete', and others will report
'VG finished'. This allows the caller to easily run a single
activation of the VG.
[--udevoutput]
can be used with --cache --listvg --checkcomplete, to enable
an output mode that prints LVM_VG_NAME_COMPLETE='vgname' that
a udev rule can import, and prevents other output from the
command (other output causes udev to ignore the command.)
The list of complete LVs is meant to be passed to lvchange -aay,
or the complete VG used with vgchange -aay.
When --checkcomplete is used, lvm assumes that that the output
will be used to trigger event-based autoactivation, so the pvscan
does nothing if event_activation=0 and --checkcomplete is used.
Example of listlvs
------------------
$ lvs -a vg -olvname,devices
LV Devices
lv_a /dev/loop0(0)
lv_ab /dev/loop0(1),/dev/loop1(1)
lv_abc /dev/loop0(3),/dev/loop1(3),/dev/loop2(1)
lv_b /dev/loop1(0)
lv_c /dev/loop2(0)
$ pvscan --cache --listlvs --checkcomplete /dev/loop0
pvscan[35680] PV /dev/loop0 online, VG vg incomplete (need 2).
VG vg incomplete
LV vg/lv_a complete
LV vg/lv_ab incomplete
LV vg/lv_abc incomplete
$ pvscan --cache --listlvs --checkcomplete /dev/loop1
pvscan[35681] PV /dev/loop1 online, VG vg incomplete (need 1).
VG vg incomplete
LV vg/lv_b complete
LV vg/lv_ab complete
LV vg/lv_abc incomplete
$ pvscan --cache --listlvs --checkcomplete /dev/loop2
pvscan[35682] PV /dev/loop2 online, VG vg is complete.
VG vg complete
LV vg/lv_c complete
LV vg/lv_abc complete
Example of listvg
-----------------
$ pvscan --cache --listvg --checkcomplete /dev/loop0
pvscan[35684] PV /dev/loop0 online, VG vg incomplete (need 2).
VG vg incomplete
$ pvscan --cache --listvg --checkcomplete /dev/loop1
pvscan[35685] PV /dev/loop1 online, VG vg incomplete (need 1).
VG vg incomplete
$ pvscan --cache --listvg --checkcomplete /dev/loop2
pvscan[35686] PV /dev/loop2 online, VG vg is complete.
VG vg complete
2020-12-09 19:59:40 +03:00
int suppress ;
2002-11-18 17:01:16 +03:00
int test ;
2021-08-19 00:26:11 +03:00
int yes ;
2002-11-18 17:01:16 +03:00
int syslog ;
int activation ;
2002-12-12 23:55:49 +03:00
int suffix ;
2002-11-18 17:01:16 +03:00
int archive ; /* should we archive ? */
int backup ; /* should we backup ? */
2007-11-09 19:51:54 +03:00
int read_ahead ; /* DM_READ_AHEAD_NONE or _AUTO */
2010-01-07 22:54:21 +03:00
int udev_rules ;
2009-08-04 19:36:13 +04:00
int udev_sync ;
2011-06-17 18:50:53 +04:00
int udev_fallback ;
2021-03-13 20:33:55 +03:00
int issue_discards ;
2021-03-24 22:19:54 +03:00
uint32_t journal ;
2005-04-06 17:47:41 +04:00
const char * msg_prefix ;
2010-04-29 05:38:12 +04:00
const char * fmt_name ;
2018-02-10 01:38:02 +03:00
const char * dmeventd_executable ;
2005-04-06 17:47:41 +04:00
uint64_t unit_factor ;
2002-11-18 17:01:16 +03:00
mode_t umask ;
2005-04-06 17:47:41 +04:00
char unit_type ;
char _padding [ 1 ] ;
2002-11-18 17:01:16 +03:00
} ;
2011-08-30 18:55:15 +04:00
struct dm_config_tree ;
2013-06-25 14:27:04 +04:00
struct profile_params ;
2005-05-17 17:46:38 +04:00
struct archive_params ;
struct backup_params ;
2010-11-11 20:29:05 +03:00
struct arg_values ;
2004-05-04 22:28:15 +04:00
2011-08-30 18:55:15 +04:00
struct config_tree_list {
struct dm_list list ;
struct dm_config_tree * cft ;
} ;
2015-07-30 10:59:39 +03:00
struct cmd_context_initialized_parts {
unsigned config : 1 ; /* used to reinitialize config if previous init was not successful */
2015-07-30 11:34:10 +03:00
unsigned filters : 1 ;
unsigned connections : 1 ;
2015-07-30 10:59:39 +03:00
} ;
2016-08-03 16:37:14 +03:00
struct cmd_report {
int log_only ;
dm_report_group_type_t report_group_type ;
struct dm_report_group * report_group ;
struct dm_report * log_rh ;
const char * log_name ;
log_report_t saved_log_report_state ;
} ;
2002-11-18 17:01:16 +03:00
/* FIXME Split into tool & library contexts */
2002-02-11 23:50:53 +03:00
/* command-instance-related variables needed by library */
struct cmd_context {
2015-07-30 17:01:02 +03:00
/*
* Memory handlers .
*/
struct dm_pool * libmem ; /* for permanent config data */
struct dm_pool * mem ; /* transient: cleared between each command */
2002-02-11 23:50:53 +03:00
2015-07-30 17:01:02 +03:00
/*
* Command line and arguments .
*/
2009-07-13 23:49:48 +04:00
const char * cmd_line ;
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
const char * name ; /* needed before cmd->command is set */
2017-01-14 00:08:51 +03:00
struct command_name * cname ;
2002-02-11 23:50:53 +03:00
struct command * command ;
2003-05-06 16:00:51 +04:00
char * * argv ;
commands: new method for defining commands
. Define a prototype for every lvm command.
. Match every user command with one definition.
. Generate help text and man pages from them.
The new file command-lines.in defines a prototype for every
unique lvm command. A unique lvm command is a unique
combination of: command name + required option args +
required positional args. Each of these prototypes also
includes the optional option args and optional positional
args that the command will accept, a description, and a
unique string ID for the definition. Any valid command
will match one of the prototypes.
Here's an example of the lvresize command definitions from
command-lines.in, there are three unique lvresize commands:
lvresize --size SizeMB LV
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync, --reportformat String, --resizefs,
--stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB
OP: PV ...
ID: lvresize_by_size
DESC: Resize an LV by a specified size.
lvresize LV PV ...
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --resizefs, --stripes Number, --stripesize SizeKB
ID: lvresize_by_pv
DESC: Resize an LV by specified PV extents.
FLAGS: SECONDARY_SYNTAX
lvresize --poolmetadatasize SizeMB LV_thinpool
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --stripes Number, --stripesize SizeKB
OP: PV ...
ID: lvresize_pool_metadata_by_size
DESC: Resize a pool metadata SubLV by a specified size.
The three commands have separate definitions because they have
different required parameters. Required parameters are specified
on the first line of the definition. Optional options are
listed after OO, and optional positional args are listed after OP.
This data is used to generate corresponding command definition
structures for lvm in command-lines.h. usage/help output is also
auto generated, so it is always in sync with the definitions.
Every user-entered command is compared against the set of
command structures, and matched with one. An error is
reported if an entered command does not have the required
parameters for any definition. The closest match is printed
as a suggestion, and running lvresize --help will display
the usage for each possible lvresize command.
The prototype syntax used for help/man output includes
required --option and positional args on the first line,
and optional --option and positional args enclosed in [ ]
on subsequent lines.
command_name <required_opt_args> <required_pos_args>
[ <optional_opt_args> ]
[ <optional_pos_args> ]
Command definitions that are not to be advertised/suggested
have the flag SECONDARY_SYNTAX. These commands will not be
printed in the normal help output.
Man page prototypes are also generated from the same original
command definitions, and are always in sync with the code
and help text.
Very early in command execution, a matching command definition
is found. lvm then knows the operation being done, and that
the provided args conform to the definition. This will allow
lots of ad hoc checking/validation to be removed throughout
the code.
Each command definition can also be routed to a specific
function to implement it. The function is associated with
an enum value for the command definition (generated from
the ID string.) These per-command-definition implementation
functions have not yet been created, so all commands
currently fall back to the existing per-command-name
implementation functions.
Using per-command-definition functions will allow lots of
code to be removed which tries to figure out what the
command is meant to do. This is currently based on ad hoc
and complicated option analysis. When using the new
functions, what the command is doing is already known
from the associated command definition.
2016-08-12 23:52:18 +03:00
struct arg_values * opt_arg_values ;
2010-11-11 20:29:05 +03:00
struct dm_list arg_value_groups ;
2018-07-23 19:08:12 +03:00
int opt_count ; /* total number of options (beginning with - or --) */
2015-07-30 10:59:39 +03:00
commands: new method for defining commands
. Define a prototype for every lvm command.
. Match every user command with one definition.
. Generate help text and man pages from them.
The new file command-lines.in defines a prototype for every
unique lvm command. A unique lvm command is a unique
combination of: command name + required option args +
required positional args. Each of these prototypes also
includes the optional option args and optional positional
args that the command will accept, a description, and a
unique string ID for the definition. Any valid command
will match one of the prototypes.
Here's an example of the lvresize command definitions from
command-lines.in, there are three unique lvresize commands:
lvresize --size SizeMB LV
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync, --reportformat String, --resizefs,
--stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB
OP: PV ...
ID: lvresize_by_size
DESC: Resize an LV by a specified size.
lvresize LV PV ...
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --resizefs, --stripes Number, --stripesize SizeKB
ID: lvresize_by_pv
DESC: Resize an LV by specified PV extents.
FLAGS: SECONDARY_SYNTAX
lvresize --poolmetadatasize SizeMB LV_thinpool
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --stripes Number, --stripesize SizeKB
OP: PV ...
ID: lvresize_pool_metadata_by_size
DESC: Resize a pool metadata SubLV by a specified size.
The three commands have separate definitions because they have
different required parameters. Required parameters are specified
on the first line of the definition. Optional options are
listed after OO, and optional positional args are listed after OP.
This data is used to generate corresponding command definition
structures for lvm in command-lines.h. usage/help output is also
auto generated, so it is always in sync with the definitions.
Every user-entered command is compared against the set of
command structures, and matched with one. An error is
reported if an entered command does not have the required
parameters for any definition. The closest match is printed
as a suggestion, and running lvresize --help will display
the usage for each possible lvresize command.
The prototype syntax used for help/man output includes
required --option and positional args on the first line,
and optional --option and positional args enclosed in [ ]
on subsequent lines.
command_name <required_opt_args> <required_pos_args>
[ <optional_opt_args> ]
[ <optional_pos_args> ]
Command definitions that are not to be advertised/suggested
have the flag SECONDARY_SYNTAX. These commands will not be
printed in the normal help output.
Man page prototypes are also generated from the same original
command definitions, and are always in sync with the code
and help text.
Very early in command execution, a matching command definition
is found. lvm then knows the operation being done, and that
the provided args conform to the definition. This will allow
lots of ad hoc checking/validation to be removed throughout
the code.
Each command definition can also be routed to a specific
function to implement it. The function is associated with
an enum value for the command definition (generated from
the ID string.) These per-command-definition implementation
functions have not yet been created, so all commands
currently fall back to the existing per-command-name
implementation functions.
Using per-command-definition functions will allow lots of
code to be removed which tries to figure out what the
command is meant to do. This is currently based on ad hoc
and complicated option analysis. When using the new
functions, what the command is doing is already known
from the associated command definition.
2016-08-12 23:52:18 +03:00
/*
* Position args remaining after command name
* and - - options are removed from original argc / argv .
*/
int position_argc ;
char * * position_argv ;
2015-07-30 17:01:02 +03:00
/*
* Format handlers .
*/
const struct format_type * fmt ; /* current format to use by default */
struct format_type * fmt_backup ; /* format to use for backups */
struct dm_list formats ; /* available formats */
struct dm_list segtypes ; /* available segment types */
/*
* Machine and system identification .
*/
const char * system_id ;
const char * hostname ;
const char * kernel_vsn ;
/*
* Device identification .
*/
struct dev_types * dev_types ; /* recognized extra device types. */
/*
* Initialization state .
*/
2015-07-30 10:59:39 +03:00
struct cmd_context_initialized_parts initialized ;
2015-07-30 17:01:02 +03:00
/*
* Switches .
*/
unsigned is_long_lived : 1 ; /* optimises persistent_filter handling */
2016-05-20 15:23:43 +03:00
unsigned is_interactive : 1 ;
2016-01-22 15:20:21 +03:00
unsigned check_pv_dev_sizes : 1 ;
2008-09-19 10:42:00 +04:00
unsigned handles_missing_pvs : 1 ;
2009-10-16 21:41:49 +04:00
unsigned handles_unknown_segments : 1 ;
2011-11-29 00:37:51 +04:00
unsigned use_linear_target : 1 ;
2008-09-19 11:12:45 +04:00
unsigned partial_activation : 1 ;
activation: Add "degraded" activation mode
Currently, we have two modes of activation, an unnamed nominal mode
(which I will refer to as "complete") and "partial" mode. The
"complete" mode requires that a volume group be 'complete' - that
is, no missing PVs. If there are any missing PVs, no affected LVs
are allowed to activate - even RAID LVs which might be able to
tolerate a failure. The "partial" mode allows anything to be
activated (or at least attempted). If a non-redundant LV is
missing a portion of its addressable space due to a device failure,
it will be replaced with an error target. RAID LVs will either
activate or fail to activate depending on how badly their
redundancy is compromised.
This patch adds a third option, "degraded" mode. This mode can
be selected via the '--activationmode {complete|degraded|partial}'
option to lvchange/vgchange. It can also be set in lvm.conf.
The "degraded" activation mode allows RAID LVs with a sufficient
level of redundancy to activate (e.g. a RAID5 LV with one device
failure, a RAID6 with two device failures, or RAID1 with n-1
failures). RAID LVs with too many device failures are not allowed
to activate - nor are any non-redundant LVs that may have been
affected. This patch also makes the "degraded" mode the default
activation mode.
The degraded activation mode does not yet work in a cluster. A
new cluster lock flag (LCK_DEGRADED_MODE) will need to be created
to make that work. Currently, there is limited space for this
extra flag and I am looking for possible solutions. One possible
solution is to usurp LCK_CONVERT, as it is not used. When the
locking_type is 3, the degraded mode flag simply gets dropped and
the old ("complete") behavior is exhibited.
2014-07-10 07:56:11 +04:00
unsigned degraded_activation : 1 ;
2013-07-12 11:27:17 +04:00
unsigned auto_set_activation_skip : 1 ;
2009-09-28 20:23:44 +04:00
unsigned si_unit_consistency : 1 ;
2014-07-02 15:16:32 +04:00
unsigned report_binary_values_as_numeric : 1 ;
2016-01-13 17:21:05 +03:00
unsigned report_mark_hidden_devices : 1 ;
2010-10-25 15:20:54 +04:00
unsigned metadata_read_only : 1 ;
2015-07-30 17:01:02 +03:00
unsigned threaded : 1 ; /* set if running within a thread e.g. clvmd */
2014-10-24 21:29:04 +04:00
unsigned unknown_system_id : 1 ;
2016-03-01 17:22:48 +03:00
unsigned include_historical_lvs : 1 ; /* also process/report/display historical LVs */
2016-03-01 17:25:14 +03:00
unsigned record_historical_lvs : 1 ; /* record historical LVs */
2019-06-21 21:37:11 +03:00
unsigned include_exported_vgs : 1 ;
2015-07-30 17:01:02 +03:00
unsigned include_foreign_vgs : 1 ; /* report/display cmds can reveal foreign VGs */
unsigned include_shared_vgs : 1 ; /* report/display cmds can reveal lockd VGs */
unsigned include_active_foreign_vgs : 1 ; /* cmd should process foreign VGs with active LVs */
unsigned vg_read_print_access_error : 1 ; /* print access errors from vg_read */
2019-08-01 18:06:47 +03:00
unsigned allow_mixed_block_sizes : 1 ;
2018-06-13 23:30:28 +03:00
unsigned force_access_clustered : 1 ;
2015-03-05 23:00:44 +03:00
unsigned lockd_gl_disable : 1 ;
unsigned lockd_vg_disable : 1 ;
unsigned lockd_lv_disable : 1 ;
2015-08-10 21:04:11 +03:00
unsigned lockd_gl_removed : 1 ;
2015-03-05 23:00:44 +03:00
unsigned lockd_vg_default_sh : 1 ;
vgchange/lvchange: enforce the shared VG lock from lvmlockd
The vgchange/lvchange activation commands read the VG, and
don't write it, so they acquire a shared VG lock from lvmlockd.
When other commands fail to acquire a shared VG lock from
lvmlockd, a warning is printed and they continue without it.
(Without it, the VG metadata they display from lvmetad may
not be up to date.)
vgchange/lvchange -a shouldn't continue without the shared
lock for a couple reasons:
. Usually they will just continue on and fail to acquire the
LV locks for activation, so continuing is pointless.
. More importantly, without the sh VG lock, the VG metadata
used by the command may be stale, and the LV locks shown
in the VG metadata may no longer be current. In the
case of sanlock, this would result in odd, unpredictable
errors when lvmlockd doesn't find the expected lock on
disk. In the case of dlm, the invalid LV lock could be
granted for the non-existing LV.
The solution is to not continue after the shared lock fails,
in the same way that a command fails if an exclusive lock fails.
2015-07-17 23:13:22 +03:00
unsigned lockd_vg_enforce_sh : 1 ;
2019-03-20 21:20:26 +03:00
unsigned lockd_lv_sh_for_ex : 1 ;
locking: unify global lock for flock and lockd
There have been two file locks used to protect lvm
"global state": "ORPHANS" and "GLOBAL".
Commands that used the ORPHAN flock in exclusive mode:
pvcreate, pvremove, vgcreate, vgextend, vgremove,
vgcfgrestore
Commands that used the ORPHAN flock in shared mode:
vgimportclone, pvs, pvscan, pvresize, pvmove,
pvdisplay, pvchange, fullreport
Commands that used the GLOBAL flock in exclusive mode:
pvchange, pvscan, vgimportclone, vgscan
Commands that used the GLOBAL flock in shared mode:
pvscan --cache, pvs
The ORPHAN lock covers the important cases of serializing
the use of orphan PVs. It also partially covers the
reporting of orphan PVs (although not correctly as
explained below.)
The GLOBAL lock doesn't seem to have a clear purpose
(it may have eroded over time.)
Neither lock correctly protects the VG namespace, or
orphan PV properties.
To simplify and correct these issues, the two separate
flocks are combined into the one GLOBAL flock, and this flock
is used from the locking sites that are in place for the
lvmlockd global lock.
The logic behind the lvmlockd (distributed) global lock is
that any command that changes "global state" needs to take
the global lock in ex mode. Global state in lvm is: the list
of VG names, the set of orphan PVs, and any properties of
orphan PVs. Reading this global state can use the global lock
in sh mode to ensure it doesn't change while being reported.
The locking of global state now looks like:
lockd_global()
previously named lockd_gl(), acquires the distributed
global lock through lvmlockd. This is unchanged.
It serializes distributed lvm commands that are changing
global state. This is a no-op when lvmlockd is not in use.
lockf_global()
acquires an flock on a local file. It serializes local lvm
commands that are changing global state.
lock_global()
first calls lockf_global() to acquire the local flock for
global state, and if this succeeds, it calls lockd_global()
to acquire the distributed lock for global state.
Replace instances of lockd_gl() with lock_global(), so that the
existing sites for lvmlockd global state locking are now also
used for local file locking of global state. Remove the previous
file locking calls lock_vol(GLOBAL) and lock_vol(ORPHAN).
The following commands which change global state are now
serialized with the exclusive global flock:
pvchange (of orphan), pvresize (of orphan), pvcreate, pvremove,
vgcreate, vgextend, vgremove, vgreduce, vgrename,
vgcfgrestore, vgimportclone, vgmerge, vgsplit
Commands that use a shared flock to read global state (and will
be serialized against the prior list) are those that use
process_each functions that are based on processing a list of
all VG names, or all PVs. The list of all VGs or all PVs is
global state and the shared lock prevents those lists from
changing while the command is processing them.
The ORPHAN lock previously attempted to produce an accurate
listing of orphan PVs, but it was only acquired at the end of
the command during the fake vg_read of the fake orphan vg.
This is not when orphan PVs were determined; they were
determined by elimination beforehand by processing all real
VGs, and subtracting the PVs in the real VGs from the list
of all PVs that had been identified during the initial scan.
This is fixed by holding the single global lock in shared mode
while processing all VGs to determine the list of orphan PVs.
2019-04-18 23:01:19 +03:00
unsigned lockd_global_ex : 1 ; /* set while global lock held ex (lockd) */
unsigned lockf_global_ex : 1 ; /* set while global lock held ex (flock) */
2019-04-25 21:34:09 +03:00
unsigned nolocking : 1 ;
2016-02-22 18:42:03 +03:00
unsigned vg_notify : 1 ;
unsigned lv_notify : 1 ;
unsigned pv_notify : 1 ;
2018-02-28 19:16:17 +03:00
unsigned activate_component : 1 ; /* command activates component LV */
unsigned process_component_lvs : 1 ; /* command processes also component LVs */
2018-03-29 22:10:58 +03:00
unsigned mirror_warn_printed : 1 ; /* command already printed warning about non-monitored mirrors */
2021-11-03 17:50:11 +03:00
unsigned expect_missing_vg_device : 1 ; /* when reading a vg it's expected that a dev for a pv isn't found */
2018-04-19 00:29:42 +03:00
unsigned can_use_one_scan : 1 ;
2018-04-25 23:08:54 +03:00
unsigned is_clvmd : 1 ;
2019-05-21 20:06:34 +03:00
unsigned md_component_detection : 1 ;
2018-05-04 01:12:07 +03:00
unsigned use_full_md_check : 1 ;
Rework lock-override options and locking_type settings
The last commit related to this was incomplete:
"Implement lock-override options without locking type"
This is further reworking and reduction of the locking.[ch]
layer which handled all clustering, but is now only used
for file locking. The "locking types" that this layer
implemented were removed previously, leaving only the
standard file locking. (Some cluster-related artifacts
remain to be cleared out later.)
Command options to override or modify locking behavior
are reimplemented here without using the locking types.
Also, deprecated locking_type values are recognized,
and implemented as if one of the equivalent override
options was set.
Options that override file locking are:
. --nolocking disables all file locking.
. --readonly grants read lock requests without actually
taking a file lock, and refuses write lock requests.
. --ignorelockingfailure tries to set up file locks and
uses them normally if possible. When not possible, it
behaves like --readonly, but allows activation.
. --sysinit is the same as ignorelockingfailure.
. global/metadata_read_only acquires actual read file
locks, and refuses write lock requests.
(Some of these options could probably be deprecated
because they were added as workarounds to various
locking_type behaviors that are now deprecated.)
The locking_type setting now has one valid value: 1 which
refers to standard file locking. Configs that contain
deprecated values are recognized and still work in
largely the same way:
. 0 disabled all locking, now implemented like --nolocking
is set. Allow the nolocking option in all commands.
. 1 is the normal file locking setting and is unchanged.
. 2 was for external locking which was not used, and
reverts to normal file locking.
. 3 was for cluster/clvm. This reverts to normal file
locking, and prints messages about lvmlockd.
. 4 was equivalent to readonly, now implemented like
--readonly is set.
. 5 disabled all locking, now implemented like
--nolocking is set.
2018-06-07 23:33:02 +03:00
unsigned is_activating : 1 ;
2018-12-07 23:35:22 +03:00
unsigned enable_hints : 1 ; /* hints are enabled for cmds in general */
unsigned use_hints : 1 ; /* if hints are enabled this cmd can use them */
unsigned pvscan_recreate_hints : 1 ; /* enable special case hint handling for pvscan --cache */
unsigned scan_lvs : 1 ;
2019-02-06 21:32:26 +03:00
unsigned wipe_outdated_pvs : 1 ;
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
unsigned enable_devices_list : 1 ; /* command is using --devices option */
unsigned enable_devices_file : 1 ; /* command is using devices file */
unsigned pending_devices_file : 1 ; /* command may create and enable devices file */
unsigned create_edit_devices_file : 1 ; /* command expects to create and/or edit devices file */
unsigned edit_devices_file : 1 ; /* command expects to edit devices file */
unsigned filter_deviceid_skip : 1 ; /* don't use filter-deviceid */
unsigned filter_regex_with_devices_file : 1 ; /* use filter-regex even when devices file is enabled */
2020-10-20 00:46:20 +03:00
unsigned filter_nodata_only : 1 ; /* only use filters that do not require data from the dev */
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
unsigned run_by_dmeventd : 1 ; /* command is being run by dmeventd */
unsigned sysinit : 1 ; /* --sysinit is used */
2021-08-19 20:57:31 +03:00
unsigned ignorelockingfailure : 1 ; /* --ignorelockingfailure is used */
2021-07-02 01:25:43 +03:00
unsigned check_devs_used : 1 ; /* check devs used by LVs */
2021-08-12 23:51:43 +03:00
unsigned print_device_id_not_found : 1 ; /* print devices file entries not found */
unsigned ignore_device_name_mismatch : 1 ; /* skip updating devices file names */
2021-10-14 19:16:49 +03:00
unsigned backup_disabled : 1 ; /* skip repeated debug message */
unsigned event_activation : 1 ; /* whether event_activation is set */
2021-11-04 00:02:38 +03:00
unsigned udevoutput : 1 ;
2018-04-19 00:29:42 +03:00
2014-10-02 14:00:57 +04:00
/*
2018-12-07 23:35:22 +03:00
* Devices and filtering .
2014-10-02 14:00:57 +04:00
*/
2018-12-04 23:06:46 +03:00
struct dev_filter * filter ;
device usage based on devices file
The LVM devices file lists devices that lvm can use. The default
file is /etc/lvm/devices/system.devices, and the lvmdevices(8)
command is used to add or remove device entries. If the file
does not exist, or if lvm.conf includes use_devicesfile=0, then
lvm will not use a devices file. When the devices file is in use,
the regex filter is not used, and the filter settings in lvm.conf
or on the command line are ignored.
LVM records devices in the devices file using hardware-specific
IDs, such as the WWID, and attempts to use subsystem-specific
IDs for virtual device types. These device IDs are also written
in the VG metadata. When no hardware or virtual ID is available,
lvm falls back using the unstable device name as the device ID.
When devnames are used, lvm performs extra scanning to find
devices if their devname changes, e.g. after reboot.
When proper device IDs are used, an lvm command will not look
at devices outside the devices file, but when devnames are used
as a fallback, lvm will scan devices outside the devices file
to locate PVs on renamed devices. A config setting
search_for_devnames can be used to control the scanning for
renamed devname entries.
Related to the devices file, the new command option
--devices <devnames> allows a list of devices to be specified for
the command to use, overriding the devices file. The listed
devices act as a sort of devices file in terms of limiting which
devices lvm will see and use. Devices that are not listed will
appear to be missing to the lvm command.
Multiple devices files can be kept in /etc/lvm/devices, which
allows lvm to be used with different sets of devices, e.g.
system devices do not need to be exposed to a specific application,
and the application can use lvm on its own set of devices that are
not exposed to the system. The option --devicesfile <filename> is
used to select the devices file to use with the command. Without
the option set, the default system devices file is used.
Setting --devicesfile "" causes lvm to not use a devices file.
An existing, empty devices file means lvm will see no devices.
The new command vgimportdevices adds PVs from a VG to the devices
file and updates the VG metadata to include the device IDs.
vgimportdevices -a will import all VGs into the system devices file.
LVM commands run by dmeventd not use a devices file by default,
and will look at all devices on the system. A devices file can
be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If
this file exists, lvm commands run by dmeventd will use it.
Internal implementaion:
- device_ids_read - read the devices file
. add struct dev_use (du) to cmd->use_devices for each devices file entry
- dev_cache_scan - get /dev entries
. add struct device (dev) to dev_cache for each device on the system
- device_ids_match - match devices file entries to /dev entries
. match each du on cmd->use_devices to a dev in dev_cache, using device ID
. on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID
- label_scan - read lvm headers and metadata from devices
. filters are applied, those that do not need data from the device
. filter-deviceid skips devs without MATCHED_USE_ID, i.e.
skips /dev entries that are not listed in the devices file
. read lvm label from dev
. filters are applied, those that use data from the device
. read lvm metadata from dev
. add info/vginfo structs for PVs/VGs (info is "lvmcache")
- device_ids_find_renamed_devs - handle devices with unstable devname ID
where devname changed
. this step only needed when devs do not have proper device IDs,
and their dev names change, e.g. after reboot sdb becomes sdc.
. detect incorrect match because PVID in the devices file entry
does not match the PVID found when the device was read above
. undo incorrect match between du and dev above
. search system devices for new location of PVID
. update devices file with new devnames for PVIDs on renamed devices
. label_scan the renamed devs
- continue with command processing
2020-06-23 21:25:41 +03:00
struct dm_list use_devices ; /* struct dev_use for each entry in devices file */
2019-05-21 20:06:34 +03:00
const char * md_component_checks ;
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
const char * search_for_devnames ; /* config file setting */
const char * devicesfile ; /* from --devicesfile option */
struct dm_list deviceslist ; /* from --devices option, struct dm_str_list */
2013-06-26 16:53:57 +04:00
2015-07-30 17:01:02 +03:00
/*
* Configuration .
*/
struct dm_list config_files ; /* master lvm config + any existing tag configs */
struct profile_params * profile_params ; /* profile handling params including loaded profile configs */
struct dm_config_tree * cft ; /* the whole cascade: CONFIG_STRING -> CONFIG_PROFILE -> CONFIG_FILE/CONFIG_MERGED_FILES */
struct dm_hash_table * cft_def_hash ; /* config definition hash used for validity check (item type + item recognized) */
struct config_info default_settings ; /* selected settings with original default/configured value which can be changed during cmd processing */
struct config_info current_settings ; /* may contain changed values compared to default_settings */
2013-06-25 14:27:04 +04:00
2015-07-30 17:01:02 +03:00
/*
* Archives and backups .
*/
2005-05-17 17:46:38 +04:00
struct archive_params * archive_params ;
struct backup_params * backup_params ;
2008-09-19 10:42:00 +04:00
const char * stripe_filler ;
2005-05-17 17:46:38 +04:00
2015-07-30 17:01:02 +03:00
/*
* Host tags .
*/
struct dm_list tags ; /* list of defined tags */
2004-05-04 22:28:15 +04:00
int hosttags ;
2004-03-08 21:13:22 +03:00
2015-07-30 17:01:02 +03:00
/*
* Paths .
*/
const char * lib_dir ; /* cache value global/library_dir */
2009-02-23 00:14:37 +03:00
char system_dir [ PATH_MAX ] ;
2002-11-18 17:01:16 +03:00
char dev_dir [ PATH_MAX ] ;
char proc_dir [ PATH_MAX ] ;
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
char devices_file_path [ PATH_MAX ] ;
2015-07-30 17:01:02 +03:00
2016-05-20 16:30:58 +03:00
/*
2016-08-03 16:37:14 +03:00
* Reporting .
2016-05-20 16:30:58 +03:00
*/
2016-08-03 16:37:14 +03:00
struct cmd_report cmd_report ;
2016-05-20 16:30:58 +03:00
2015-07-30 17:01:02 +03:00
/*
* Buffers .
*/
char display_buffer [ NAME_LEN * 10 ] ; /* ring buffer for upto 10 longest vg/lv names */
unsigned display_lvname_idx ; /* index to ring buffer */
char * linebuffer ;
/*
* Others - unsorted .
*/
2015-07-30 17:14:10 +03:00
const char * report_list_item_separator ;
2015-07-30 17:01:02 +03:00
const char * time_format ;
unsigned rand_seed ;
2019-08-23 14:08:34 +03:00
struct dm_list pending_delete ; /* list of LVs for removal */
2019-08-27 13:18:47 +03:00
struct dm_pool * pending_delete_mem ; /* memory pool for pending deletes */
2002-02-11 23:50:53 +03:00
} ;
2009-02-23 00:14:37 +03:00
/*
* system_dir may be NULL to use the default value .
* The environment variable LVM_SYSTEM_DIR always takes precedence .
*/
2018-05-03 00:58:49 +03:00
struct cmd_context * create_toolcontext ( unsigned is_clvmd ,
2011-05-07 17:50:11 +04:00
const char * system_dir ,
2011-12-09 01:24:08 +04:00
unsigned set_buffering ,
2015-07-30 11:34:10 +03:00
unsigned threaded ,
unsigned set_connections ,
unsigned set_filters ) ;
2002-11-18 17:01:16 +03:00
void destroy_toolcontext ( struct cmd_context * cmd ) ;
2004-03-08 21:13:22 +03:00
int refresh_toolcontext ( struct cmd_context * cmd ) ;
2009-11-24 19:10:25 +03:00
int refresh_filters ( struct cmd_context * cmd ) ;
2014-03-17 19:03:53 +04:00
int process_profilable_config ( struct cmd_context * cmd ) ;
2004-05-04 22:28:15 +04:00
int config_files_changed ( struct cmd_context * cmd ) ;
2008-04-08 16:49:21 +04:00
int init_lvmcache_orphans ( struct cmd_context * cmd ) ;
2015-07-30 11:34:10 +03:00
int init_filters ( struct cmd_context * cmd , unsigned load_persistent_cache ) ;
int init_connections ( struct cmd_context * cmd ) ;
2017-01-23 16:21:56 +03:00
int init_run_by_dmeventd ( struct cmd_context * cmd ) ;
2002-11-18 17:01:16 +03:00
2016-05-17 19:54:13 +03:00
/*
* A config context is a very light weight cmd struct that
* is only used for reading config settings from lvm . conf ,
* which are at cmd - > cft .
*/
struct cmd_context * create_config_context ( void ) ;
void destroy_config_context ( struct cmd_context * cmd ) ;
2010-04-29 05:38:12 +04:00
struct format_type * get_format_by_name ( struct cmd_context * cmd , const char * format ) ;
2015-02-24 02:03:52 +03:00
const char * system_id_from_string ( struct cmd_context * cmd , const char * str ) ;
2014-10-24 21:29:04 +04:00
2002-02-11 23:50:53 +03:00
# endif