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 .
2014-10-18 12:58:23 +04:00
* Copyright ( C ) 2004 - 2014 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 .
2001-09-25 16:49:28 +04: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 .
2001-09-25 16:49:28 +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-11-18 17:04:08 +03:00
/*********** Replace with script?
xx ( e2fsadm ,
" Resize logical volume and ext2 filesystem " ,
" e2fsadm "
2014-10-18 12:58:23 +04:00
" [-d|--debug] " " [-h|--help] " " [-n|--nofsck] \n "
" \t {[-l|--extents] [+|-]LogicalExtentsNumber | \n "
" \t [-L|--size] [+|-]LogicalVolumeSize[bBsSkKmMgGtTpPeE]} \n "
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t LogicalVolumePath \n " ,
2002-11-18 17:04:08 +03:00
extents_ARG , size_ARG , nofsck_ARG , test_ARG )
* * * * * * * * */
2015-04-28 19:00:37 +03:00
xx ( config ,
" Display and manipulate configuration information " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2015-04-28 19:00:37 +03:00
" config \n "
" \t [-f|--file filename] \n "
2015-11-25 16:09:20 +03:00
" \t [--type {current|default|diff|full|list|missing|new|profilable|profilable-command|profilable-metadata}] \n "
" \t [--atversion version] \n "
2015-04-28 19:00:37 +03:00
" \t [--ignoreadvanced] \n "
" \t [--ignoreunsupported] \n "
" \t [--ignorelocal] \n "
2015-04-29 12:11:58 +03:00
" \t [-l|--list] \n "
2015-04-28 19:00:37 +03:00
" \t [--config ConfigurationString] \n "
" \t [--commandprofile ProfileName] \n "
" \t [--profile ProfileName] \n "
" \t [--metadataprofile ProfileName] \n "
" \t [--mergedconfig] \n "
2015-11-25 16:09:20 +03:00
" \t [--sinceversion version] \n "
2015-04-30 18:40:24 +03:00
" \t [--showdeprecated] \n "
2015-04-29 17:07:52 +03:00
" \t [--showunsupported] \n "
2015-04-28 19:00:37 +03:00
" \t [--validate] \n "
2015-04-29 11:53:25 +03:00
" \t [--withsummary] \n "
2015-04-28 19:00:37 +03:00
" \t [--withcomments] \n "
2015-06-24 14:28:40 +03:00
" \t [--withspaces] \n "
2015-04-28 19:00:37 +03:00
" \t [--unconfigured] \n "
" \t [--withversions] \n "
" \t [ConfigurationNode...] \n " ,
atversion_ARG , configtype_ARG , file_ARG , ignoreadvanced_ARG ,
2015-04-29 12:11:58 +03:00
ignoreunsupported_ARG , ignorelocal_ARG , list_ARG , mergedconfig_ARG , metadataprofile_ARG ,
2015-11-25 16:09:20 +03:00
sinceversion_ARG , showdeprecated_ARG , showunsupported_ARG , validate_ARG , withsummary_ARG ,
withcomments_ARG , withspaces_ARG , unconfigured_ARG , withversions_ARG )
2015-04-28 19:00:37 +03:00
2013-09-18 04:09:15 +04:00
xx ( devtypes ,
" Display recognised built-in block device types " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2014-10-18 12:58:23 +04:00
" devtypes \n "
2013-09-18 04:09:15 +04:00
" \t [--aligned] \n "
2014-07-02 15:16:32 +04:00
" \t [--binary] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2013-09-18 04:09:15 +04:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [--nameprefixes] \n "
" \t [--noheadings] \n "
" \t [--nosuffix] \n "
2015-10-30 17:43:57 +03:00
" \t [-o|--options [+|-|#]Field[,Field]] \n "
2013-09-18 04:09:15 +04:00
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
2016-05-02 15:39:32 +03:00
" \t [--reportformat {basic|json}] \n "
2013-09-18 04:09:15 +04:00
" \t [--rows] \n "
2014-06-13 14:57:22 +04:00
" \t [-S|--select Selection] \n "
2013-09-18 04:09:15 +04:00
" \t [--separator Separator] \n "
" \t [--unbuffered] \n "
" \t [--unquoted] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n " ,
2013-09-18 04:09:15 +04:00
2016-05-02 15:39:32 +03:00
aligned_ARG , binary_ARG , nameprefixes_ARG , noheadings_ARG ,
nosuffix_ARG , options_ARG , reportformat_ARG , rows_ARG ,
select_ARG , separator_ARG , sort_ARG , unbuffered_ARG , unquoted_ARG )
2013-09-18 04:09:15 +04:00
2003-10-16 00:17:19 +04:00
xx ( dumpconfig ,
2015-04-28 19:00:37 +03:00
" Display and manipulate configuration information " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2013-03-05 20:48:29 +04:00
" dumpconfig \n "
2014-10-18 12:58:23 +04:00
" \t [-f|--file filename] \n "
2015-11-25 16:09:20 +03:00
" \t [--type {current|default|diff|full|list|missing|new|profilable|profilable-command|profilable-metadata}] \n "
" \t [--atversion version] \n "
2014-10-18 12:58:23 +04:00
" \t [--ignoreadvanced] \n "
" \t [--ignoreunsupported] \n "
2015-04-21 22:53:54 +03:00
" \t [--ignorelocal] \n "
2015-04-29 12:11:58 +03:00
" \t [-l|--list] \n "
2014-10-18 12:58:23 +04:00
" \t [--config ConfigurationString] \n "
" \t [--commandprofile ProfileName] \n "
" \t [--profile ProfileName] \n "
" \t [--metadataprofile ProfileName] \n "
" \t [--mergedconfig] \n "
2015-11-25 16:09:20 +03:00
" \t [--sinceversion version] \n "
2015-04-30 18:40:24 +03:00
" \t [--showdeprecated] \n "
2015-04-29 17:07:52 +03:00
" \t [--showunsupported] \n "
2013-03-05 20:48:29 +04:00
" \t [--validate] \n "
2015-04-29 11:53:25 +03:00
" \t [--withsummary] \n "
2014-10-18 12:58:23 +04:00
" \t [--withcomments] \n "
2015-06-24 14:14:30 +03:00
" \t [--withspaces] \n "
2015-04-17 19:31:16 +03:00
" \t [--unconfigured] \n "
2014-10-18 12:58:23 +04:00
" \t [--withversions] \n "
2013-03-05 20:48:29 +04:00
" \t [ConfigurationNode...] \n " ,
2013-07-19 22:24:54 +04:00
atversion_ARG , configtype_ARG , file_ARG , ignoreadvanced_ARG ,
2015-04-29 12:11:58 +03:00
ignoreunsupported_ARG , ignorelocal_ARG , list_ARG , mergedconfig_ARG , metadataprofile_ARG ,
2015-11-25 16:09:20 +03:00
sinceversion_ARG , showdeprecated_ARG , showunsupported_ARG , validate_ARG , withsummary_ARG ,
withcomments_ARG , withspaces_ARG , unconfigured_ARG , withversions_ARG )
2003-10-16 00:17:19 +04:00
2004-09-14 20:42:46 +04:00
xx ( formats ,
" List available metadata formats " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2004-09-14 20:42:46 +04:00
" formats \n " )
2001-09-25 16:49:28 +04:00
xx ( help ,
" Display help for commands " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2014-10-18 12:58:23 +04:00
" help <command> \n " )
2001-09-25 16:49:28 +04:00
2001-10-08 22:44:22 +04:00
/*********
2001-09-25 16:49:28 +04:00
xx ( lvactivate ,
" Activate logical volume on given partition(s) " ,
2001-10-04 14:13:07 +04:00
" lvactivate "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [-v|--verbose] \n "
2001-10-04 14:13:07 +04:00
" Logical Volume(s) \n " )
2001-10-08 22:44:22 +04:00
* * * * * * * * * * */
2001-09-25 16:49:28 +04:00
2016-05-03 12:18:16 +03:00
xx ( fullreport ,
" Display full report " ,
PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT | LOCKD_VG_SH ,
" fullreport \n "
" \t [--aligned] \n "
" \t [--binary] \n "
" \t [-a|--all] \n "
" \t [--commandprofile ProfileName] \n "
2016-06-20 12:57:24 +03:00
" \t [--configreport ReportName] \n "
2016-05-03 12:18:16 +03:00
" \t [-d|--debug] \n "
" \t [--foreign] \n "
" \t [-h|--help] \n "
" \t [--ignorelockingfailure] \n "
" \t [--ignoreskippedcluster] \n "
2016-06-15 14:35:27 +03:00
" \t [--logonly] \n "
2016-05-03 12:18:16 +03:00
" \t [--nameprefixes] \n "
" \t [--noheadings] \n "
" \t [--nosuffix] \n "
" \t [-o|--options [+|-|#]Field[,Field]] \n "
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
" \t [-P|--partial] \n "
" \t [--readonly] \n "
2016-06-24 15:49:13 +03:00
" \t [--reportformat {basic|json}] \n "
2016-05-03 12:18:16 +03:00
" \t [--rows] \n "
" \t [-S|--select Selection] \n "
" \t [--separator Separator] \n "
" \t [--trustcache] \n "
" \t [--unbuffered] \n "
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
" \t [--unquoted] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t [VolumeGroupName [VolumeGroupName...]] \n " ,
2016-06-20 12:57:24 +03:00
aligned_ARG , all_ARG , binary_ARG , configreport_ARG , foreign_ARG ,
ignorelockingfailure_ARG , ignoreskippedcluster_ARG , logonly_ARG ,
nameprefixes_ARG , noheadings_ARG , nolocking_ARG , nosuffix_ARG ,
options_ARG , partial_ARG , readonly_ARG , reportformat_ARG , rows_ARG ,
select_ARG , separator_ARG , shared_ARG , sort_ARG , trustcache_ARG ,
unbuffered_ARG , units_ARG , unquoted_ARG )
2016-05-03 12:18:16 +03:00
2016-05-20 16:30:58 +03:00
xx ( lastlog ,
" Display last command's log report " ,
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
" log \n "
2016-06-24 15:49:13 +03:00
" \t [--reportformat {basic|json}] \n "
2016-05-20 16:30:58 +03:00
" \t [-S|--select Selection] \n " ,
reportformat_ARG , select_ARG )
2001-09-25 16:49:28 +04:00
xx ( lvchange ,
" Change the attributes of logical volume(s) " ,
2010-10-25 15:20:54 +04:00
CACHE_VGMETADATA | PERMITTED_READ_ONLY ,
2001-09-25 16:49:28 +04:00
" lvchange \n "
2015-09-22 01:06:40 +03:00
" \t [-A|--autobackup {y|n}] \n "
" \t [-a|--activate [a][e|s|l]{y|n}] \n "
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
" \t [--activationmode {complete|degraded|partial} "
2015-09-22 01:06:40 +03:00
" \t [--addtag <Tag>] \n "
" \t [--alloc <AllocationPolicy>] \n "
2016-08-05 16:54:49 +03:00
" \t [--rebuild PhysicalVolume] \n "
2015-09-22 01:06:40 +03:00
" \t [-C|--contiguous {y|n}] \n "
2016-04-25 14:39:30 +03:00
" \t [--cachemode <CacheMode>] \n "
2015-09-22 01:06:40 +03:00
" \t [--cachepolicy <policyname>] [--cachesettings <parameter=value>] \n "
" \t [--commandprofile <ProfileName>] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
2015-09-22 01:06:40 +03:00
" \t [--deltag <Tag>] \n "
2013-06-25 14:33:06 +04:00
" \t [--detachprofile] \n "
2015-01-15 17:20:08 +03:00
" \t [--errorwhenfull {y|n}] \n "
2003-07-11 21:10:19 +04:00
" \t [-f|--force] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|--help] \n "
2012-08-08 00:24:41 +04:00
" \t [--discards {ignore|nopassdown|passdown}] \n "
2002-11-18 17:04:08 +03:00
" \t [--ignorelockingfailure] \n "
2007-06-18 18:14:33 +04:00
" \t [--ignoremonitoring] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2013-07-11 14:44:36 +04:00
" \t [-k|--setactivationskip {y|n}] \n "
2014-10-18 12:58:23 +04:00
" \t [-K|--ignoreactivationskip] \n "
2006-05-12 23:16:48 +04:00
" \t [--monitor {y|n}] \n "
2010-01-05 23:56:51 +03:00
" \t [--poll {y|n}] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
2015-09-22 01:06:40 +03:00
" \t [-M|--persistent {y|n}] [-j|--major <major>] [--minor <minor>] \n "
" \t [--metadataprofile <ProfileName>] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2015-09-22 01:06:40 +03:00
" \t [-p|--permission {r|rw}] \n "
" \t [--[raid]minrecoveryrate <Rate>] \n "
" \t [--[raid]maxrecoveryrate <Rate>] \n "
2013-07-19 22:24:54 +04:00
" \t [--[raid]syncaction {check|repair} \n "
2015-09-22 01:06:40 +03:00
" \t [--[raid]writebehind <IOCount>] \n "
" \t [--[raid]writemostly <PhysicalVolume>[:{t|n|y}]] \n "
" \t [-r|--readahead <ReadAheadSectors>|auto|none] \n "
2004-03-27 00:24:03 +03:00
" \t [--refresh] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2006-10-24 21:19:48 +04:00
" \t [--resync] \n "
2014-12-03 12:03:48 +03:00
" \t [-S|--select Selection] \n "
2010-05-06 15:15:55 +04:00
" \t [--sysinit] \n "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2012-06-28 16:52:23 +04:00
" \t [--version] \n "
2013-05-14 21:45:37 +04:00
" \t [-y|--yes] \n "
2012-06-28 16:52:23 +04:00
" \t [-Z|--zero {y|n}] \n "
2015-09-22 01:06:40 +03:00
" \t <LogicalVolume[Path]> [<LogicalVolume[Path]>...] \n " ,
2001-09-25 16:49:28 +04:00
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
activationmode_ARG , addtag_ARG , alloc_ARG , autobackup_ARG , activate_ARG ,
2016-04-25 14:39:30 +03:00
available_ARG , cachemode_ARG , cachepolicy_ARG , cachesettings_ARG ,
contiguous_ARG , deltag_ARG ,
2014-12-03 12:03:48 +03:00
discards_ARG , detachprofile_ARG , errorwhenfull_ARG , force_ARG ,
2013-07-19 22:24:54 +04:00
ignorelockingfailure_ARG , ignoremonitoring_ARG , ignoreactivationskip_ARG ,
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
ignoreskippedcluster_ARG , major_ARG , metadataprofile_ARG , minor_ARG ,
monitor_ARG , minrecoveryrate_ARG , maxrecoveryrate_ARG , noudevsync_ARG ,
partial_ARG , permission_ARG , persistent_ARG , poll_ARG ,
2016-08-05 16:54:49 +03:00
raidrebuild_ARG , raidminrecoveryrate_ARG , raidmaxrecoveryrate_ARG ,
raidsyncaction_ARG , raidwritebehind_ARG , raidwritemostly_ARG , readahead_ARG ,
reportformat_ARG , rebuild_ARG , resync_ARG , refresh_ARG , select_ARG , setactivationskip_ARG ,
syncaction_ARG , sysinit_ARG , test_ARG , writebehind_ARG , writemostly_ARG , zero_ARG )
2001-09-25 16:49:28 +04:00
2014-07-08 00:54:33 +04:00
# define COMMON_OPTS \
2016-03-05 23:02:30 +03:00
" \t [--commandprofile <ProfileName>] [-d|--debug] [-h|-?|--help] \n " \
2014-07-08 00:54:33 +04:00
" \t [--noudevsync] [-t|--test] [-v|--verbose] [--version] [-y|--yes] \n "
2005-06-06 21:12:08 +04:00
xx ( lvconvert ,
" Change logical volume layout " ,
2008-04-03 01:23:39 +04:00
0 ,
2006-04-06 00:43:23 +04:00
" lvconvert "
2016-03-05 23:02:30 +03:00
" [-m|--mirrors <Mirrors> [--mirrorlog {disk|core|mirrored}|--corelog]] \n "
" \t [--type <SegmentType>] \n "
2016-08-05 16:54:49 +03:00
" \t [--rebuild PhysicalVolume] \n "
2009-06-04 16:01:15 +04:00
" \t [--repair [--use-policies]] \n "
2011-11-30 06:02:10 +04:00
" \t [--replace PhysicalVolume] \n "
2016-03-05 23:02:30 +03:00
" \t [-R|--regionsize <MirrorLogRegionSize>] \n "
" \t [--alloc <AllocationPolicy>] \n "
2007-12-22 15:13:29 +03:00
" \t [-b|--background] \n "
2009-06-30 22:39:31 +04:00
" \t [-f|--force] \n "
2016-03-05 23:02:30 +03:00
" \t [-i|--interval <Seconds>] \n "
" \t [--stripes <Stripes> [-I|--stripesize <StripeSize>]] \n "
2014-07-08 00:54:33 +04:00
COMMON_OPTS
2006-04-06 00:43:23 +04:00
" \t LogicalVolume[Path] [PhysicalVolume[Path]...] \n \n "
This patch adds the capability to split off a mirror legs.
It is pretty much the same as reducing the number of
mirror legs, but we just don't delete them afterwards.
The following command line interface is enforced:
prompt> lvconvert --splitmirror <n> -n <name> <VG>/<LV>
where 'n' is the number of images to split off, and
where 'name' is the name of the newly split off logical volume.
If more than one leg is split off, a new mirror will be the
result. The newly split off mirror will have a 'core' log.
Example:
[root@bp-01 LVM2]# !lvs
lvs -a -o name,copy_percent,devices
LV Copy% Devices
lv 100.00 lv_mimage_0(0),lv_mimage_1(0),lv_mimage_2(0),lv_mimage_3(0)
[lv_mimage_0] /dev/sdb1(0)
[lv_mimage_1] /dev/sdc1(0)
[lv_mimage_2] /dev/sdd1(0)
[lv_mimage_3] /dev/sde1(0)
[lv_mlog] /dev/sdi1(0)
[root@bp-01 LVM2]# lvconvert --splitmirrors 2 --name split vg/lv /dev/sd[ce]1
Logical volume lv converted.
[root@bp-01 LVM2]# !lvs
lvs -a -o name,copy_percent,devices
LV Copy% Devices
lv 100.00 lv_mimage_0(0),lv_mimage_2(0)
[lv_mimage_0] /dev/sdb1(0)
[lv_mimage_2] /dev/sdd1(0)
[lv_mlog] /dev/sdi1(0)
split 100.00 split_mimage_0(0),split_mimage_1(0)
[split_mimage_0] /dev/sde1(0)
[split_mimage_1] /dev/sdc1(0)
It can be seen that '--splitmirror <n>' is exactly the same
as '--mirrors -<n>' (note the minus sign), except there is the
additional notion to keep the image being detached from the
mirror instead of just throwing it away.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
2010-01-09 01:00:31 +03:00
" lvconvert "
2016-03-05 23:02:30 +03:00
" [--splitmirrors <Images> --trackchanges] \n "
2014-07-08 00:54:33 +04:00
" \t [--splitmirrors Images --name SplitLogicalVolumeName] \n "
COMMON_OPTS
This patch adds the capability to split off a mirror legs.
It is pretty much the same as reducing the number of
mirror legs, but we just don't delete them afterwards.
The following command line interface is enforced:
prompt> lvconvert --splitmirror <n> -n <name> <VG>/<LV>
where 'n' is the number of images to split off, and
where 'name' is the name of the newly split off logical volume.
If more than one leg is split off, a new mirror will be the
result. The newly split off mirror will have a 'core' log.
Example:
[root@bp-01 LVM2]# !lvs
lvs -a -o name,copy_percent,devices
LV Copy% Devices
lv 100.00 lv_mimage_0(0),lv_mimage_1(0),lv_mimage_2(0),lv_mimage_3(0)
[lv_mimage_0] /dev/sdb1(0)
[lv_mimage_1] /dev/sdc1(0)
[lv_mimage_2] /dev/sdd1(0)
[lv_mimage_3] /dev/sde1(0)
[lv_mlog] /dev/sdi1(0)
[root@bp-01 LVM2]# lvconvert --splitmirrors 2 --name split vg/lv /dev/sd[ce]1
Logical volume lv converted.
[root@bp-01 LVM2]# !lvs
lvs -a -o name,copy_percent,devices
LV Copy% Devices
lv 100.00 lv_mimage_0(0),lv_mimage_2(0)
[lv_mimage_0] /dev/sdb1(0)
[lv_mimage_2] /dev/sdd1(0)
[lv_mlog] /dev/sdi1(0)
split 100.00 split_mimage_0(0),split_mimage_1(0)
[split_mimage_0] /dev/sde1(0)
[split_mimage_1] /dev/sdc1(0)
It can be seen that '--splitmirror <n>' is exactly the same
as '--mirrors -<n>' (note the minus sign), except there is the
additional notion to keep the image being detached from the
mirror instead of just throwing it away.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
2010-01-09 01:00:31 +03:00
" \t LogicalVolume[Path] [SplittablePhysicalVolume[Path]...] \n \n "
2013-12-04 06:09:37 +04:00
" lvconvert "
" --splitsnapshot \n "
2014-07-08 00:54:33 +04:00
COMMON_OPTS
2013-12-04 06:09:37 +04:00
" \t SnapshotLogicalVolume[Path] \n \n "
2014-10-04 17:32:24 +04:00
" lvconvert "
" --splitcache \n "
COMMON_OPTS
" \t CacheLogicalVolume[Path] \n \n "
" lvconvert "
" --split \n "
" \t [--name SplitLogicalVolumeName] \n "
COMMON_OPTS
" \t SplitableLogicalVolume[Path] \n \n "
" lvconvert "
" --uncache \n "
COMMON_OPTS
" \t CacheLogicalVolume[Path] \n \n "
2006-04-06 00:43:23 +04:00
" lvconvert "
2014-07-08 00:54:33 +04:00
" [--type snapshot|-s|--snapshot] \n "
2016-03-05 23:02:30 +03:00
" \t [-c|--chunksize <ChunkSize>] \n "
2006-04-06 00:43:23 +04:00
" \t [-Z|--zero {y|n}] \n "
2014-07-08 00:54:33 +04:00
COMMON_OPTS
2010-01-13 04:45:15 +03:00
" \t OriginalLogicalVolume[Path] SnapshotLogicalVolume[Path] \n \n "
" lvconvert "
" --merge \n "
" \t [-b|--background] \n "
2016-03-05 23:02:30 +03:00
" \t [-i|--interval <Seconds>] \n "
2014-07-08 00:54:33 +04:00
COMMON_OPTS
2012-05-09 16:17:06 +04:00
" \t LogicalVolume[Path] \n \n "
" lvconvert "
2014-07-08 00:54:33 +04:00
" [--type thin[-pool]|-T|--thin] \n "
" \t [--thinpool ThinPoolLogicalVolume[Path]] \n "
2016-03-05 23:02:30 +03:00
" \t [--chunksize <ChunkSize>] \n "
2012-05-14 15:57:30 +04:00
" \t [--discards {ignore|nopassdown|passdown}] \n "
2014-07-08 00:54:33 +04:00
" \t [--poolmetadataspare {y|n}] \n "
2016-03-05 23:02:30 +03:00
" \t [--poolmetadata ThinMetadataLogicalVolume[Path] | \n "
" \t --poolmetadatasize <MetadataSize>] \n "
" \t [-r|--readahead <ReadAheadSectors>|auto|none] \n "
" \t [--stripes <Stripes> [-I|--stripesize <StripeSize>]]] \n "
2014-07-08 00:54:33 +04:00
" \t [--originname NewExternalOriginVolumeName]] \n "
2012-05-14 15:57:30 +04:00
" \t [-Z|--zero {y|n}] \n "
2014-07-08 00:54:33 +04:00
COMMON_OPTS
2014-10-23 00:43:42 +04:00
" \t [ExternalOrigin|ThinDataPool]LogicalVolume[Path] [PhysicalVolumePath...] \n \n "
2005-06-06 21:12:08 +04:00
2014-02-12 19:51:42 +04:00
" lvconvert "
2014-10-23 00:43:42 +04:00
" [--type cache[-pool]|-H|--cache] \n "
2014-07-08 00:54:33 +04:00
" \t [--cachepool CacheDataLogicalVolume[Path]] \n "
2016-03-05 23:02:30 +03:00
" \t [--cachemode <CacheMode>] \n "
" \t [--cachepolicy <CachePolicy>] \n "
" \t [--cachesettings <Key>=<Value>] \n "
" \t [--chunksize <ChunkSize>] \n "
" \t [--poolmetadata CacheMetadataLogicalVolume[Path] | \n "
" \t --poolmetadatasize <MetadataSize>] \n "
2014-07-08 00:54:33 +04:00
" \t [--poolmetadataspare {y|n}]] \n "
COMMON_OPTS
2014-10-23 00:43:42 +04:00
" \t [Cache|CacheDataPool]LogicalVolume[Path] [PhysicalVolumePath...] \n \n " ,
2014-02-12 19:51:42 +04:00
2015-08-21 14:00:13 +03:00
alloc_ARG , background_ARG , cache_ARG , cachemode_ARG ,
cachepool_ARG , cachepolicy_ARG , cachesettings_ARG , chunksize_ARG ,
2014-02-12 19:51:42 +04:00
corelog_ARG , discards_ARG , force_ARG , interval_ARG , merge_ARG , mirrorlog_ARG ,
mirrors_ARG , name_ARG , noudevsync_ARG , originname_ARG , poolmetadata_ARG ,
poolmetadatasize_ARG , poolmetadataspare_ARG , readahead_ARG , regionsize_ARG ,
2014-10-04 17:32:24 +04:00
repair_ARG , replace_ARG , snapshot_ARG ,
split_ARG , splitcache_ARG , splitmirrors_ARG , splitsnapshot_ARG ,
2013-12-04 06:09:37 +04:00
stripes_long_ARG , stripesize_ARG , test_ARG , thin_ARG , thinpool_ARG ,
2016-02-08 15:09:37 +03:00
trackchanges_ARG , type_ARG , uncache_ARG , usepolicies_ARG , zero_ARG )
2005-06-06 21:12:08 +04:00
2001-09-25 16:49:28 +04:00
xx ( lvcreate ,
" Create a logical volume " ,
2008-04-03 01:23:39 +04:00
0 ,
2014-10-18 12:58:23 +04:00
" lvcreate \n "
2002-02-18 13:59:51 +03:00
" \t [-A|--autobackup {y|n}] \n "
2012-06-28 12:15:07 +04:00
" \t [-a|--activate [a|e|l]{y|n}] \n "
2004-03-08 20:19:15 +03:00
" \t [--addtag Tag] \n "
2004-11-16 21:09:32 +03:00
" \t [--alloc AllocationPolicy] \n "
2014-09-30 23:46:02 +04:00
" \t [-H|--cache \n "
" \t [--cachemode {writeback|writethrough}] \n "
2015-08-21 14:00:13 +03:00
" \t [--cachepolicy policy] \n "
" \t [--cachesettings key=value] \n "
2014-09-30 23:46:02 +04:00
" \t [--cachepool CachePoolLogicalVolume{Name|Path}] \n "
2014-10-18 12:58:23 +04:00
" \t [-c|--chunksize ChunkSize] \n "
2002-02-18 13:59:51 +03:00
" \t [-C|--contiguous {y|n}] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-02-18 13:59:51 +03:00
" \t [-d|--debug] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|-?|--help] \n "
2015-01-13 17:23:03 +03:00
" \t [--errorwhenfull {y|n}] \n "
2010-03-24 01:30:18 +03:00
" \t [--ignoremonitoring] \n "
" \t [--monitor {y|n}] \n "
2002-02-18 13:59:51 +03:00
" \t [-i|--stripes Stripes [-I|--stripesize StripeSize]] \n "
2013-07-10 16:06:50 +04:00
" \t [-k|--setactivationskip {y|n}] \n "
2014-10-18 12:58:23 +04:00
" \t [-K|--ignoreactivationskip] \n "
2010-02-03 06:58:08 +03:00
" \t {-l|--extents LogicalExtentsNumber[%{VG|PVS|FREE}] | \n "
2009-07-06 23:13:26 +04:00
" \t -L|--size LogicalVolumeSize[bBsSkKmMgGtTpPeE]} \n "
2014-10-23 00:43:42 +04:00
" \t [-M|--persistent {y|n}] [-j|--major major] [--minor minor] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--metadataprofile ProfileName] \n "
2014-10-23 00:43:42 +04:00
" \t [-m|--mirrors Mirrors [--nosync] \n "
" \t [{--mirrorlog {disk|core|mirrored}|--corelog}]] \n "
2002-02-18 13:59:51 +03:00
" \t [-n|--name LogicalVolumeName] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
2002-02-18 13:59:51 +03:00
" \t [-p|--permission {r|rw}] \n "
2014-11-24 19:38:39 +03:00
//"\t[--pooldatasize DataSize[bBsSkKmMgGtTpPeE]]\n"
2014-10-18 12:58:23 +04:00
" \t [--poolmetadatasize MetadataSize[bBsSkKmMgG]] \n "
" \t [--poolmetadataspare {y|n}]] \n "
2013-07-19 22:24:54 +04:00
" \t [--[raid]minrecoveryrate Rate] \n "
" \t [--[raid]maxrecoveryrate Rate] \n "
2014-10-23 00:43:42 +04:00
" \t [-r|--readahead {ReadAheadSectors|auto|none}] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2005-06-01 20:51:55 +04:00
" \t [-R|--regionsize MirrorLogRegionSize] \n "
2014-09-30 23:46:02 +04:00
" \t [-T|--thin \n "
2012-08-09 14:20:47 +04:00
" \t [--discards {ignore|nopassdown|passdown}] \n "
" \t [--thinpool ThinPoolLogicalVolume{Name|Path}] \n "
2002-02-18 13:59:51 +03:00
" \t [-t|--test] \n "
2004-05-11 20:01:58 +04:00
" \t [--type VolumeType] \n "
2002-02-18 13:59:51 +03:00
" \t [-v|--verbose] \n "
2013-11-06 19:05:50 +04:00
" \t [-W|--wipesignatures {y|n}] \n "
2002-02-18 13:59:51 +03:00
" \t [-Z|--zero {y|n}] \n "
" \t [--version] \n "
2002-11-29 18:02:57 +03:00
" \t VolumeGroupName [PhysicalVolumePath...] \n \n "
2002-11-28 18:27:29 +03:00
2014-10-18 12:58:23 +04:00
" lvcreate \n "
2009-05-27 20:30:29 +04:00
" \t { {-s|--snapshot} OriginalLogicalVolume[Path] | \n "
2011-08-17 19:15:36 +04:00
" \t [-s|--snapshot] VolumeGroupName[Path] -V|--virtualsize VirtualSize} \n "
2014-10-18 12:58:23 +04:00
" \t {-H|--cache} VolumeGroupName[Path][/OriginalLogicalVolume] \n "
" \t {-T|--thin} VolumeGroupName[Path][/PoolLogicalVolume] \n "
2011-09-06 04:26:42 +04:00
" \t -V|--virtualsize VirtualSize} \n "
2002-11-28 18:27:29 +03:00
" \t [-A|--autobackup {y|n}] \n "
2004-03-08 20:19:15 +03:00
" \t [--addtag Tag] \n "
2004-11-16 21:09:32 +03:00
" \t [--alloc AllocationPolicy] \n "
2014-11-27 22:21:41 +03:00
" \t [--cachepolicy Policy] [--cachesettings Key=Value] \n "
2014-10-18 12:58:23 +04:00
" \t [-c|--chunksize] \n "
2002-11-28 18:27:29 +03:00
" \t [-C|--contiguous {y|n}] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-28 18:27:29 +03:00
" \t [-d|--debug] \n "
2012-08-08 00:24:41 +04:00
" \t [--discards {ignore|nopassdown|passdown}] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|-?|--help] \n "
2010-03-24 01:30:18 +03:00
" \t [--ignoremonitoring] \n "
" \t [--monitor {y|n}] \n "
2002-11-28 18:27:29 +03:00
" \t [-i|--stripes Stripes [-I|--stripesize StripeSize]] \n "
2013-07-19 22:24:54 +04:00
" \t [-k|--setactivationskip {y|n}] \n "
2014-10-18 12:58:23 +04:00
" \t [-K|--ignoreactivationskip] \n "
2010-02-03 06:58:08 +03:00
" \t {-l|--extents LogicalExtentsNumber[%{VG|FREE|ORIGIN}] | \n "
2009-07-06 23:13:26 +04:00
" \t -L|--size LogicalVolumeSize[bBsSkKmMgGtTpPeE]} \n "
2014-11-24 19:38:39 +03:00
//"\t[--pooldatasize DataVolumeSize[bBsSkKmMgGtTpPeE]]\n"
2013-06-11 15:45:49 +04:00
" \t [--poolmetadatasize MetadataVolumeSize[bBsSkKmMgG]] \n "
2014-10-23 00:43:42 +04:00
" \t [-M|--persistent {y|n}] [-j|--major major] [--minor minor] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--metadataprofile ProfileName] \n "
2002-11-28 18:27:29 +03:00
" \t [-n|--name LogicalVolumeName] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
2002-11-28 18:27:29 +03:00
" \t [-p|--permission {r|rw}] \n "
2007-11-09 19:51:54 +03:00
" \t [-r|--readahead ReadAheadSectors|auto|none] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2002-11-28 18:27:29 +03:00
" \t [-t|--test] \n "
2014-10-18 12:58:23 +04:00
" \t [{--thinpool ThinPoolLogicalVolume[Path] | \n "
" \t --cachepool CachePoolLogicalVolume[Path]}] \n "
2002-11-28 18:27:29 +03:00
" \t [-v|--verbose] \n "
" \t [--version] \n "
2009-04-25 05:17:59 +04:00
" \t [PhysicalVolumePath...] \n \n " ,
2001-12-03 23:23:53 +03:00
2012-06-27 15:48:31 +04:00
addtag_ARG , alloc_ARG , autobackup_ARG , activate_ARG , available_ARG ,
2014-11-27 22:21:41 +03:00
cache_ARG , cachemode_ARG , cachepool_ARG , cachepolicy_ARG , cachesettings_ARG ,
2015-01-13 17:23:03 +03:00
chunksize_ARG , contiguous_ARG , corelog_ARG , discards_ARG , errorwhenfull_ARG ,
2014-02-04 21:57:08 +04:00
extents_ARG , ignoreactivationskip_ARG , ignoremonitoring_ARG , major_ARG ,
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
metadataprofile_ARG , minor_ARG , mirrorlog_ARG , mirrors_ARG , monitor_ARG ,
minrecoveryrate_ARG , maxrecoveryrate_ARG , name_ARG , nosync_ARG ,
2014-10-18 12:58:30 +04:00
noudevsync_ARG , permission_ARG , persistent_ARG ,
2014-11-24 19:38:39 +03:00
//pooldatasize_ARG,
poolmetadatasize_ARG , poolmetadataspare_ARG ,
2014-10-18 12:58:30 +04:00
raidminrecoveryrate_ARG , raidmaxrecoveryrate_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
readahead_ARG , regionsize_ARG , reportformat_ARG , setactivationskip_ARG ,
size_ARG , snapshot_ARG , stripes_ARG , stripesize_ARG , test_ARG , thin_ARG ,
thinpool_ARG , type_ARG , virtualoriginsize_ARG , virtualsize_ARG ,
wipesignatures_ARG , zero_ARG )
2001-09-25 16:49:28 +04:00
xx ( lvdisplay ,
" Display information about a logical volume " ,
2015-03-05 23:00:44 +03:00
PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT | LOCKD_VG_SH ,
2001-09-25 16:49:28 +04:00
" lvdisplay \n "
2005-06-03 18:49:51 +04:00
" \t [-a|--all] \n "
2002-11-29 18:02:57 +03:00
" \t [-c|--colon] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|--help] \n "
2016-03-04 12:27:45 +03:00
" \t [-H|--history] \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2002-11-29 18:02:57 +03:00
" \t [-m|--maps] \n "
2002-12-12 23:55:49 +03:00
" \t [--nosuffix] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2016-06-24 15:49:13 +03:00
" \t [--reportformat {basic|json}] \n "
2014-12-12 12:20:15 +03:00
" \t [-S|--select Selection] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2002-11-29 18:02:57 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2002-12-12 23:55:49 +03:00
" \t [LogicalVolume[Path] [LogicalVolume[Path]...]] \n "
" \n "
" lvdisplay --columns|-C \n "
" \t [--aligned] \n "
2005-06-03 18:49:51 +04:00
" \t [-a|--all] \n "
2014-12-11 17:16:04 +03:00
" \t [--binary] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2016-06-20 12:57:24 +03:00
" \t [--configreport ReportName] \n "
2002-12-12 23:55:49 +03:00
" \t [-d|--debug] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2002-12-12 23:55:49 +03:00
" \t [-h|--help] \n "
2016-03-04 12:27:45 +03:00
" \t [-H|--history] \n "
2002-12-12 23:55:49 +03:00
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2016-06-15 14:35:27 +03:00
" \t [--logonly] \n "
2002-12-12 23:55:49 +03:00
" \t [--noheadings] \n "
" \t [--nosuffix] \n "
2015-10-30 17:43:57 +03:00
" \t [-o|--options [+|-|#]Field[,Field]] \n "
2002-12-12 23:55:49 +03:00
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
2014-05-29 11:39:11 +04:00
" \t [-S|--select Selection] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2002-12-12 23:55:49 +03:00
" \t [--segments] \n "
" \t [--separator Separator] \n "
" \t [--unbuffered] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2002-12-12 23:55:49 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2002-12-12 23:55:49 +03:00
" \t [LogicalVolume[Path] [LogicalVolume[Path]...]] \n " ,
2001-09-25 16:49:28 +04:00
2016-06-20 12:57:24 +03:00
aligned_ARG , all_ARG , binary_ARG , colon_ARG , columns_ARG ,
2016-06-24 12:10:10 +03:00
configreport_ARG , foreign_ARG , history_ARG , ignorelockingfailure_ARG ,
2016-06-20 12:57:24 +03:00
ignoreskippedcluster_ARG , logonly_ARG , maps_ARG , noheadings_ARG ,
nosuffix_ARG , options_ARG , sort_ARG , partial_ARG , readonly_ARG ,
reportformat_ARG , segments_ARG , select_ARG , separator_ARG ,
shared_ARG , unbuffered_ARG , units_ARG )
2001-09-25 16:49:28 +04:00
xx ( lvextend ,
" Add space to a logical volume " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-09-25 16:49:28 +04:00
" lvextend \n "
2002-11-29 18:02:57 +03:00
" \t [-A|--autobackup y|n] \n "
2004-11-16 21:09:32 +03:00
" \t [--alloc AllocationPolicy] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
2008-06-12 17:24:02 +04:00
" \t [-f|--force] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|--help] \n "
2001-11-27 16:42:37 +03:00
" \t [-i|--stripes Stripes [-I|--stripesize StripeSize]] \n "
2010-02-03 06:58:08 +03:00
" \t {-l|--extents [+]LogicalExtentsNumber[%{VG|LV|PVS|FREE|ORIGIN}] | \n "
2009-07-06 23:13:26 +04:00
" \t -L|--size [+]LogicalVolumeSize[bBsSkKmMgGtTpPeE]} \n "
2013-06-11 15:45:49 +04:00
" \t --poolmetadatasize [+]MetadataVolumeSize[bBsSkKmMgG]} \n "
2005-06-03 23:48:19 +04:00
" \t [-m|--mirrors Mirrors] \n "
Allow 'nosync' extension of mirrors.
This patch allows a mirror to be extended without an initial resync of the
extended portion. It compliments the existing '--nosync' option to lvcreate.
This action can be done implicitly if the mirror was created with the '--nosync'
option, or explicitly if the '--nosync' option is used when extending the device.
Here are the operational criteria:
1) A mirror created with '--nosync' should extend with 'nosync' implicitly
[EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg
LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert
lv vg Mwi-a-m- 5.00g lv_mlog 100.00
Extending 2 mirror images.
Extending logical volume lv to 10.00 GiB
Logical volume lv successfully resized
LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert
lv vg Mwi-a-m- 10.00g lv_mlog 100.00
2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm'
signifies a mirror created w/o '--nosync') must be preserved when extending a
mirror created with '--nosync'. See #1 for example of 'M' attribute.
3) A mirror created without '--nosync' should extend with 'nosync' only when
'--nosync' is explicitly used when extending.
[EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg
LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert
lv vg mwi-a-m- 20.00m lv_mlog 100.00
Extending 2 mirror images.
Extending logical volume lv to 5.02 GiB
Logical volume lv successfully resized
LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert
lv vg mwi-a-m- 5.02g lv_mlog 0.39
vs.
[EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg
LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert
lv vg mwi-a-m- 20.00m lv_mlog 100.00
Extending 2 mirror images.
Extending logical volume lv to 5.02 GiB
Logical volume lv successfully resized
LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert
lv vg Mwi-a-m- 5.02g lv_mlog 100.00
4) The 'm' attribute must change to 'M' when extending a mirror created without
'--nosync' is extended with the '--nosync' option. (See #3 examples above.)
5) An inactive mirror's sync percent cannot be determined definitively, so it
must not be allowed to skip resync. Instead, the extend should ask the user if
they want to extend while performing a resync.
[EXAMPLE]# lvchange -an vg/lv
[EXAMPLE]# lvextend -L +5G vg/lv
Extending 2 mirror images.
Extending logical volume lv to 10.00 GiB
vg/lv is not active. Unable to get sync percent.
Do full resync of extended portion of vg/lv? [y/n]: y
Logical volume lv successfully resized
6) A mirror that is performing recovery (as opposed to an initial sync) - like
after a failure - is not allowed to extend with either an implicit or
explicit nosync option. [You can simulate this with a 'corelog' mirror because
when it is reactivated, it must be recovered every time.]
[EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog
WARNING: New mirror won't be synchronised. Don't read what you didn't write!
Logical volume "lv" created
[EXAMPLE]# lvs vg
LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert
lv vg Mwi-a-m- 5.00g 100.00
[EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg
LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert
lv vg Mwi-a-m- 5.00g 0.08
[EXAMPLE]# lvextend -L +5G vg/lv
Extending 2 mirror images.
Extending logical volume lv to 10.00 GiB
vg/lv cannot be extended while it is recovering.
7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not
result in the mirror being resized or the 'm/M' attribute being changed.
NOTE: A mirror created with '--nosync' behaves differently than one created
without it when performing an extension. The former cannot be extended when
the mirror is recovering (unless in-active), while the latter can. This is
a reasonable thing to do since recovery of a mirror doesn't take long (at
least in the case of an on-disk log) and it would cause far more time in
degraded mode if the extension w/o '--nosync' was allowed. It might be
reasonable to add the ability to force the operation in the future. This
should /not/ force a nosync extension, but rather force a sync'ed extension.
IOW, the user would be saying, "Yes, yes... I know recovery won't take long
and that I'll be adding significantly to the time spent in degraded mode, but
I need the extra space right now!".
2011-10-06 19:32:26 +04:00
" \t [--nosync] \n "
2010-10-15 20:28:14 +04:00
" \t [--use-policies] \n "
2004-06-15 21:23:49 +04:00
" \t [-n|--nofsck] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2004-06-15 21:23:49 +04:00
" \t [-r|--resizefs] \n "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
2004-05-11 20:01:58 +04:00
" \t [--type VolumeType] \n "
2002-11-29 18:02:57 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-09-25 16:49:28 +04:00
" \t LogicalVolume[Path] [ PhysicalVolumePath... ] \n " ,
2008-06-12 17:24:02 +04:00
alloc_ARG , autobackup_ARG , extents_ARG , force_ARG , mirrors_ARG ,
2013-06-11 15:45:49 +04:00
nofsck_ARG , nosync_ARG , noudevsync_ARG , poolmetadatasize_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
reportformat_ARG , resizefs_ARG , size_ARG , stripes_ARG , stripesize_ARG ,
2016-02-08 15:09:37 +03:00
test_ARG , type_ARG , usepolicies_ARG )
2001-09-25 16:49:28 +04:00
xx ( lvmchange ,
2001-12-03 23:23:53 +03:00
" With the device mapper, this is obsolete and does nothing. " ,
2008-04-03 01:23:39 +04:00
0 ,
2002-02-11 14:43:17 +03:00
" lvmchange \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [-R|--reset] \n "
2002-12-12 23:55:49 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n " ,
2001-09-25 16:49:28 +04:00
2001-12-03 23:23:53 +03:00
reset_ARG )
2001-09-25 16:49:28 +04:00
2015-04-28 19:00:37 +03:00
xx ( lvmconfig ,
" Display and manipulate configuration information " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2015-04-28 19:00:37 +03:00
" lvmconfig \n "
" \t [-f|--file filename] \n "
2015-11-25 16:09:20 +03:00
" \t [--type {current|default|diff|full|list|missing|new|profilable|profilable-command|profilable-metadata}] \n "
" \t [--atversion version] \n "
2015-04-28 19:00:37 +03:00
" \t [--ignoreadvanced] \n "
" \t [--ignoreunsupported] \n "
" \t [--ignorelocal] \n "
2015-04-29 12:11:58 +03:00
" \t [-l|--list] \n "
2015-04-28 19:00:37 +03:00
" \t [--config ConfigurationString] \n "
" \t [--commandprofile ProfileName] \n "
" \t [--profile ProfileName] \n "
" \t [--metadataprofile ProfileName] \n "
" \t [--mergedconfig] \n "
2015-11-25 16:09:20 +03:00
" \t [--sinceversion version] \n "
2015-04-30 18:40:24 +03:00
" \t [--showdeprecated] \n "
2015-04-29 17:07:52 +03:00
" \t [--showunsupported] \n "
2015-04-28 19:00:37 +03:00
" \t [--validate] \n "
2015-04-29 11:53:25 +03:00
" \t [--withsummary] \n "
2015-04-28 19:00:37 +03:00
" \t [--withcomments] \n "
2015-06-24 14:28:40 +03:00
" \t [--withspaces] \n "
2015-04-28 19:00:37 +03:00
" \t [--unconfigured] \n "
" \t [--withversions] \n "
" \t [ConfigurationNode...] \n " ,
atversion_ARG , configtype_ARG , file_ARG , ignoreadvanced_ARG ,
2015-04-29 12:11:58 +03:00
ignoreunsupported_ARG , ignorelocal_ARG , list_ARG , mergedconfig_ARG , metadataprofile_ARG ,
2015-11-25 16:09:20 +03:00
sinceversion_ARG , showdeprecated_ARG , showunsupported_ARG , validate_ARG , withsummary_ARG ,
withcomments_ARG , withspaces_ARG , unconfigured_ARG , withversions_ARG )
2015-04-28 19:00:37 +03:00
2001-09-25 16:49:28 +04:00
xx ( lvmdiskscan ,
" List devices that may be used as physical volumes " ,
2014-10-02 01:58:23 +04:00
PERMITTED_READ_ONLY | ENABLE_ALL_DEVS ,
2001-09-25 16:49:28 +04:00
" lvmdiskscan \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
2002-12-12 23:55:49 +03:00
" \t [-l|--lvmpartition] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n " ,
2001-09-25 16:49:28 +04:00
2014-04-18 05:46:34 +04:00
lvmpartition_ARG , readonly_ARG )
2001-09-25 16:49:28 +04:00
xx ( lvmsadc ,
" Collect activity data " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-09-25 16:49:28 +04:00
" lvmsadc \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
" \t [LogFilePath] \n " )
2001-09-25 16:49:28 +04:00
xx ( lvmsar ,
" Create activity report " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-09-25 16:49:28 +04:00
" lvmsar \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-f|--full] \n "
" \t [-h|--help] \n "
" \t [-s|--stdin] \n "
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-09-25 16:49:28 +04:00
" \t LogFilePath \n " ,
2002-11-28 18:27:29 +03:00
full_ARG , stdin_ARG )
2001-09-25 16:49:28 +04:00
xx ( lvreduce ,
" Reduce the size of a logical volume " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-09-25 16:49:28 +04:00
" lvreduce \n "
2002-11-29 18:02:57 +03:00
" \t [-A|--autobackup y|n] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-f|--force] \n "
" \t [-h|--help] \n "
2010-02-03 06:58:08 +03:00
" \t {-l|--extents [-]LogicalExtentsNumber[%{VG|LV|FREE|ORIGIN}] | \n "
2009-07-06 23:13:26 +04:00
" \t -L|--size [-]LogicalVolumeSize[bBsSkKmMgGtTpPeE]} \n "
2004-06-15 21:23:49 +04:00
" \t [-n|--nofsck] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
2004-06-15 21:23:49 +04:00
" \t [-r|--resizefs] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2013-05-14 21:45:37 +04:00
" \t [-y|--yes] \n "
2001-09-25 16:49:28 +04:00
" \t LogicalVolume[Path] \n " ,
2009-08-04 19:53:04 +04:00
autobackup_ARG , force_ARG , extents_ARG , nofsck_ARG , noudevsync_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
reportformat_ARG , resizefs_ARG , size_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
xx ( lvremove ,
" Remove logical volume(s) from the system " ,
2014-12-12 11:34:50 +03:00
ALL_VGS_IS_DEFAULT , /* all VGs only with --select */
2001-09-25 16:49:28 +04:00
" lvremove \n "
2002-11-29 18:02:57 +03:00
" \t [-A|--autobackup y|n] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-f|--force] \n "
" \t [-h|--help] \n "
2016-03-01 17:25:37 +03:00
" \t [--nohistory] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-12-12 11:34:50 +03:00
" \t [-S|--select Selection] \n "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-09-25 16:49:28 +04:00
" \t LogicalVolume[Path] [LogicalVolume[Path]...] \n " ,
2016-03-01 17:27:08 +03:00
autobackup_ARG , force_ARG , nohistory_ARG , noudevsync_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
reportformat_ARG , select_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
xx ( lvrename ,
" Rename a logical volume " ,
2008-04-03 01:23:39 +04:00
0 ,
2011-08-04 14:12:44 +04:00
" lvrename \n "
2014-10-18 12:58:23 +04:00
" \t [-A|--autobackup {y|n}] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-h|-?|--help] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-10-18 12:58:23 +04:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t { OldLogicalVolumePath NewLogicalVolumePath | \n "
2001-12-03 23:23:53 +03:00
" \t VolumeGroupName OldLogicalVolumeName NewLogicalVolumeName } \n " ,
2001-09-25 16:49:28 +04:00
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
autobackup_ARG , noudevsync_ARG , reportformat_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
2001-11-13 17:17:50 +03:00
xx ( lvresize ,
" Resize a logical volume " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-11-13 17:17:50 +03:00
" lvresize \n "
2002-11-29 18:02:57 +03:00
" \t [-A|--autobackup y|n] \n "
2004-11-16 21:09:32 +03:00
" \t [--alloc AllocationPolicy] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
2008-06-12 17:24:02 +04:00
" \t [-f|--force] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|--help] \n "
2001-11-27 16:42:37 +03:00
" \t [-i|--stripes Stripes [-I|--stripesize StripeSize]] \n "
2010-02-03 06:58:08 +03:00
" \t {-l|--extents [+|-]LogicalExtentsNumber[%{VG|LV|PVS|FREE|ORIGIN}] | \n "
2009-07-06 23:13:26 +04:00
" \t -L|--size [+|-]LogicalVolumeSize[bBsSkKmMgGtTpPeE]} \n "
2013-06-11 15:45:49 +04:00
" \t --poolmetadatasize [+]MetadataVolumeSize[bBsSkKmMgG]} \n "
2004-06-15 21:23:49 +04:00
" \t [-n|--nofsck] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2004-06-15 21:23:49 +04:00
" \t [-r|--resizefs] \n "
2001-11-28 21:03:11 +03:00
" \t [-t|--test] \n "
2004-05-11 20:01:58 +04:00
" \t [--type VolumeType] \n "
2002-11-29 18:02:57 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-11-13 17:17:50 +03:00
" \t LogicalVolume[Path] [ PhysicalVolumePath... ] \n " ,
2008-06-12 17:24:02 +04:00
alloc_ARG , autobackup_ARG , extents_ARG , force_ARG , nofsck_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
noudevsync_ARG , reportformat_ARG , resizefs_ARG ,
poolmetadatasize_ARG , size_ARG , stripes_ARG , stripesize_ARG ,
2009-08-04 19:53:04 +04:00
test_ARG , type_ARG )
2001-11-13 17:17:50 +03:00
2002-12-12 23:55:49 +03:00
xx ( lvs ,
" Display information about logical volumes " ,
2015-03-05 23:00:44 +03:00
PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT | LOCKD_VG_SH ,
2014-10-18 12:58:23 +04:00
" lvs \n "
2005-06-03 18:49:51 +04:00
" \t [-a|--all] \n "
2002-12-12 23:55:49 +03:00
" \t [--aligned] \n "
2014-07-02 15:16:32 +04:00
" \t [--binary] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2016-06-16 16:49:18 +03:00
" \t [--configreport ReportName] \n "
2002-12-12 23:55:49 +03:00
" \t [-d|--debug] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2002-12-12 23:55:49 +03:00
" \t [-h|--help] \n "
2016-03-01 17:23:34 +03:00
" \t [-H|--history] \n "
2002-12-12 23:55:49 +03:00
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2016-06-15 14:35:27 +03:00
" \t [--logonly] \n "
2008-06-06 23:28:35 +04:00
" \t [--nameprefixes] \n "
2002-12-12 23:55:49 +03:00
" \t [--noheadings] \n "
" \t [--nosuffix] \n "
2015-10-30 17:43:57 +03:00
" \t [-o|--options [+|-|#]Field[,Field]] \n "
2002-12-12 23:55:49 +03:00
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2016-05-02 15:39:32 +03:00
" \t [--reportformat {basic|json}] \n "
2008-06-25 02:48:53 +04:00
" \t [--rows] \n "
2002-12-12 23:55:49 +03:00
" \t [--segments] \n "
2014-05-29 11:38:59 +04:00
" \t [-S|--select Selection] \n "
2002-12-12 23:55:49 +03:00
" \t [--separator Separator] \n "
2006-08-01 18:56:33 +04:00
" \t [--trustcache] \n "
2002-12-12 23:55:49 +03:00
" \t [--unbuffered] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2008-06-25 01:21:04 +04:00
" \t [--unquoted] \n "
2002-12-12 23:55:49 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2002-12-12 23:55:49 +03:00
" \t [LogicalVolume[Path] [LogicalVolume[Path]...]] \n " ,
2006-05-12 23:16:48 +04:00
2016-06-16 16:49:18 +03:00
aligned_ARG , all_ARG , binary_ARG , configreport_ARG , foreign_ARG , history_ARG ,
2016-06-15 14:35:27 +03:00
ignorelockingfailure_ARG , ignoreskippedcluster_ARG , logonly_ARG ,
nameprefixes_ARG , noheadings_ARG , nolocking_ARG , nosuffix_ARG ,
options_ARG , partial_ARG , readonly_ARG , reportformat_ARG , rows_ARG ,
segments_ARG , select_ARG , separator_ARG , shared_ARG , sort_ARG ,
trustcache_ARG , unbuffered_ARG , units_ARG , unquoted_ARG )
2002-12-12 23:55:49 +03:00
2001-09-25 16:49:28 +04:00
xx ( lvscan ,
" List all logical volumes in all volume groups " ,
2016-01-29 01:40:26 +03:00
PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT | LOCKD_VG_SH | NO_LVMETAD_AUTOSCAN ,
2014-10-18 12:58:23 +04:00
" lvscan \n "
2005-10-17 20:41:38 +04:00
" \t [-a|--all] \n "
2014-10-18 12:58:23 +04:00
" \t [-b|--blockdevice] \n "
2014-07-21 05:55:46 +04:00
" \t [--cache] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-h|-?|--help] \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-10-18 12:58:23 +04:00
" \t [-v|--verbose] \n "
2001-12-03 23:23:53 +03:00
" \t [--version] \n " ,
2001-09-25 16:49:28 +04:00
2014-04-18 05:46:34 +04:00
all_ARG , blockdevice_ARG , ignorelockingfailure_ARG , partial_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
readonly_ARG , reportformat_ARG , cache_long_ARG )
2001-09-25 16:49:28 +04:00
xx ( pvchange ,
" Change attributes of physical volume(s) " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-09-25 16:49:28 +04:00
" pvchange \n "
2004-01-13 21:42:05 +03:00
" \t [-a|--all] \n "
2002-11-29 18:02:57 +03:00
" \t [-A|--autobackup y|n] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
2010-07-07 23:14:57 +04:00
" \t [-f|--force] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|--help] \n "
2015-02-12 19:37:47 +03:00
" \t [--ignoreskippedcluster] \n "
" \t [--metadataignore y|n] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-12-03 12:03:48 +03:00
" \t [-S|--select Selection] \n "
2001-11-28 21:03:11 +03:00
" \t [-t|--test] \n "
2004-01-13 21:42:05 +03:00
" \t [-u|--uuid] \n "
2002-11-29 18:02:57 +03:00
" \t [-x|--allocatable y|n] \n "
2004-01-13 21:42:05 +03:00
" \t [-v|--verbose] \n "
2004-03-08 20:19:15 +03:00
" \t [--addtag Tag] \n "
" \t [--deltag Tag] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-09-25 16:49:28 +04:00
" \t [PhysicalVolumePath...] \n " ,
2004-03-08 20:19:15 +03:00
all_ARG , allocatable_ARG , allocation_ARG , autobackup_ARG , deltag_ARG ,
2015-02-12 19:37:47 +03:00
addtag_ARG , force_ARG , ignoreskippedcluster_ARG , metadataignore_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
reportformat_ARG , select_ARG , test_ARG , uuid_ARG )
2001-09-25 16:49:28 +04:00
2005-10-31 05:37:29 +03:00
xx ( pvresize ,
" Resize physical volume(s) " ,
2008-04-03 01:23:39 +04:00
0 ,
2014-10-18 12:58:23 +04:00
" pvresize \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-h|-?|--help] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-10-18 12:58:23 +04:00
" \t [--setphysicalvolumesize PhysicalVolumeSize[bBsSkKmMgGtTpPeE] \n "
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
2005-10-31 05:37:29 +03:00
" \t PhysicalVolume [PhysicalVolume...] \n " ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
physicalvolumesize_ARG , reportformat_ARG , test_ARG )
2005-10-31 05:37:29 +03:00
2007-03-31 01:00:26 +04:00
xx ( pvck ,
" Check the consistency of physical volume(s) " ,
2015-03-05 23:00:44 +03:00
LOCKD_VG_SH ,
2007-03-31 01:00:26 +04:00
" pvck "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2007-03-31 01:00:26 +04:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
2014-10-18 12:58:23 +04:00
" \t [--labelsector sector] \n "
2007-03-31 01:00:26 +04:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2007-04-26 00:03:16 +04:00
" \t PhysicalVolume [PhysicalVolume...] \n " ,
labelsector_ARG )
2007-03-31 01:00:26 +04:00
2001-09-25 16:49:28 +04:00
xx ( pvcreate ,
" Initialize physical volume(s) for use by LVM " ,
2016-02-16 23:15:24 +03:00
ENABLE_ALL_DEVS ,
2014-10-18 12:58:23 +04:00
" pvcreate \n "
2010-08-12 08:08:59 +04:00
" \t [--norestorefile] \n "
2002-11-18 17:04:08 +03:00
" \t [--restorefile file] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-f[f]|--force [--force]] \n "
" \t [-h|-?|--help] \n "
" \t [--labelsector sector] \n "
" \t [-M|--metadatatype 1|2] \n "
" \t [--pvmetadatacopies #copies] \n "
" \t [--bootloaderareasize BootLoaderAreaSize[bBsSkKmMgGtTpPeE]] \n "
" \t [--metadatasize MetadataSize[bBsSkKmMgGtTpPeE]] \n "
" \t [--dataalignment Alignment[bBsSkKmMgGtTpPeE]] \n "
" \t [--dataalignmentoffset AlignmentOffset[bBsSkKmMgGtTpPeE]] \n "
" \t [--setphysicalvolumesize PhysicalVolumeSize[bBsSkKmMgGtTpPeE] \n "
" \t [-t|--test] \n "
" \t [-u|--uuid uuid] \n "
" \t [-v|--verbose] \n "
" \t [-y|--yes] \n "
2005-01-05 20:25:25 +03:00
" \t [-Z|--zero {y|n}] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-12-03 23:23:53 +03:00
" \t PhysicalVolume [PhysicalVolume...] \n " ,
2001-09-25 16:49:28 +04:00
2013-05-28 14:37:22 +04:00
dataalignment_ARG , dataalignmentoffset_ARG , bootloaderareasize_ARG ,
2013-02-15 14:14:26 +04:00
force_ARG , test_ARG , labelsector_ARG , metadatatype_ARG ,
metadatacopies_ARG , metadatasize_ARG , metadataignore_ARG ,
norestorefile_ARG , physicalvolumesize_ARG , pvmetadatacopies_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
reportformat_ARG , restorefile_ARG , uuidstr_ARG , zero_ARG )
2001-09-25 16:49:28 +04:00
xx ( pvdata ,
" Display the on-disk metadata for physical volume(s) " ,
2008-04-03 01:23:39 +04:00
0 ,
2014-10-18 12:58:23 +04:00
" pvdata \n "
" \t [-a|--all] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-E|--physicalextent] \n "
" \t [-h|-?|--help] \n "
" \t [-L|--logicalvolume] \n "
" \t [-P[P]|--physicalvolume [--physicalvolume]] \n "
" \t [-U|--uuidlist] \n "
" \t [-v[v]|--verbose [--verbose]] \n "
" \t [-V|--volumegroup] \n "
" \t [--version] \n "
2001-12-03 23:23:53 +03:00
" \t PhysicalVolume [PhysicalVolume...] \n " ,
2001-09-25 16:49:28 +04:00
all_ARG , logicalextent_ARG , physicalextent_ARG ,
physicalvolume_ARG , uuidlist_ARG , volumegroup_ARG )
xx ( pvdisplay ,
2002-12-12 23:55:49 +03:00
" Display various attributes of physical volume(s) " ,
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
CACHE_VGMETADATA | PERMITTED_READ_ONLY | ENABLE_ALL_DEVS | ENABLE_DUPLICATE_DEVS | LOCKD_VG_SH ,
2001-09-25 16:49:28 +04:00
" pvdisplay \n "
2002-11-29 18:02:57 +03:00
" \t [-c|--colon] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|--help] \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2002-11-29 18:02:57 +03:00
" \t [-m|--maps] \n "
2002-12-12 23:55:49 +03:00
" \t [--nosuffix] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2016-06-24 15:49:13 +03:00
" \t [--reportformat {basic|json}] \n "
2014-12-12 12:20:15 +03:00
" \t [-S|--select Selection] \n "
2002-11-29 18:02:57 +03:00
" \t [-s|--short] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2002-11-29 18:02:57 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2002-12-12 23:55:49 +03:00
" \t [PhysicalVolumePath [PhysicalVolumePath...]] \n "
" \n "
" pvdisplay --columns|-C \n "
" \t [--aligned] \n "
2005-03-21 17:47:36 +03:00
" \t [-a|--all] \n "
2014-12-11 17:16:04 +03:00
" \t [--binary] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2016-06-20 12:57:24 +03:00
" \t [--configreport ReportName] \n "
2002-12-12 23:55:49 +03:00
" \t [-d|--debug] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2002-12-12 23:55:49 +03:00
" \t [-h|--help] \n "
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2016-06-15 14:35:27 +03:00
" \t [--logonly] \n "
2002-12-12 23:55:49 +03:00
" \t [--noheadings] \n "
" \t [--nosuffix] \n "
2015-10-30 17:43:57 +03:00
" \t [-o|--options [+|-|#]Field[,Field]] \n "
2002-12-12 23:55:49 +03:00
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-05-29 11:39:11 +04:00
" \t [-S|--select Selection] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2002-12-12 23:55:49 +03:00
" \t [--separator Separator] \n "
" \t [--unbuffered] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2002-12-12 23:55:49 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2002-12-12 23:55:49 +03:00
" \t [PhysicalVolumePath [PhysicalVolumePath...]] \n " ,
2001-09-25 16:49:28 +04:00
2016-06-20 12:57:24 +03:00
aligned_ARG , all_ARG , binary_ARG , colon_ARG , columns_ARG , configreport_ARG ,
foreign_ARG , ignorelockingfailure_ARG , ignoreskippedcluster_ARG ,
logonly_ARG , maps_ARG , noheadings_ARG , nosuffix_ARG , options_ARG ,
readonly_ARG , reportformat_ARG , select_ARG , separator_ARG , shared_ARG ,
short_ARG , sort_ARG , unbuffered_ARG , units_ARG )
2001-09-25 16:49:28 +04:00
2016-06-03 17:56:48 +03:00
/* ALL_VGS_IS_DEFAULT is for polldaemon to find pvmoves in-progress using process_each_vg. */
2001-09-25 16:49:28 +04:00
xx ( pvmove ,
" Move extents from one physical volume to another " ,
2016-06-03 17:56:48 +03:00
ALL_VGS_IS_DEFAULT | DISALLOW_TAG_ARGS ,
2014-10-18 12:58:23 +04:00
" pvmove \n "
2003-05-06 16:08:58 +04:00
" \t [--abort] \n "
2014-06-19 16:40:47 +04:00
" \t [--alloc AllocationPolicy] \n "
pvmove: Enable all-or-nothing (atomic) pvmoves
pvmove can be used to move single LVs by name or multiple LVs that
lie within the specified PV range (e.g. /dev/sdb1:0-1000). When
moving more than one LV, the portions of those LVs that are in the
range to be moved are added to a new temporary pvmove LV. The LVs
then point to the range in the pvmove LV, rather than the PV
range.
Example 1:
We have two LVs in this example. After they were
created, the first LV was grown, yeilding two segments
in LV1. So, there are two LVs with a total of three
segments.
Before pvmove:
--------- --------- ---------
| LV1s0 | | LV2s0 | | LV1s1 |
--------- --------- ---------
| | |
-------------------------------------
PV | 000 - 255 | 256 - 511 | 512 - 767 |
-------------------------------------
After pvmove inserts the temporary pvmove LV:
--------- --------- ---------
| LV1s0 | | LV2s0 | | LV1s1 |
--------- --------- ---------
| | |
-------------------------------------
pvmove0 | seg 0 | seg 1 | seg 2 |
-------------------------------------
| | |
-------------------------------------
PV | 000 - 255 | 256 - 511 | 512 - 767 |
-------------------------------------
Each of the affected LV segments now point to a
range of blocks in the pvmove LV, which purposefully
corresponds to the segments moved from the original
LVs into the temporary pvmove LV.
The current implementation goes on from here to mirror the temporary
pvmove LV by segment. Further, as the pvmove LV is activated, only
one of its segments is actually mirrored (i.e. "moving") at a time.
The rest are either complete or not addressed yet. If the pvmove
is aborted, those segments that are completed will remain on the
destination and those that are not yet addressed or in the process
of moving will stay on the source PV. Thus, it is possible to have
a partially completed move - some LVs (or certain segments of LVs)
on the source PV and some on the destination.
Example 2:
What 'example 1' might look if it was half-way
through the move.
--------- --------- ---------
| LV1s0 | | LV2s0 | | LV1s1 |
--------- --------- ---------
| | |
-------------------------------------
pvmove0 | seg 0 | seg 1 | seg 2 |
-------------------------------------
| | |
| -------------------------
source PV | | 256 - 511 | 512 - 767 |
| -------------------------
| ||
-------------------------
dest PV | 000 - 255 | 256 - 511 |
-------------------------
This update allows the user to specify that they would like the
pvmove mirror created "by LV" rather than "by segment". That is,
the pvmove LV becomes an image in an encapsulating mirror along
with the allocated copy image.
Example 3:
A pvmove that is performed "by LV" rather than "by segment".
--------- ---------
| LV1s0 | | LV2s0 |
--------- ---------
| |
-------------------------
pvmove0 | * LV-level mirror * |
-------------------------
/ \
pvmove_mimage0 / pvmove_mimage1
------------------------- -------------------------
| seg 0 | seg 1 | | seg 0 | seg 1 |
------------------------- -------------------------
| | | |
------------------------- -------------------------
| 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 |
------------------------- -------------------------
source PV dest PV
The thing that differentiates a pvmove done in this way and a simple
"up-convert" from linear to mirror is the preservation of the
distinct segments. A normal up-convert would simply allocate the
necessary space with no regard for segment boundaries. The pvmove
operation must preserve the segments because they are the critical
boundary between the segments of the LVs being moved. So, when the
pvmove copy image is allocated, all corresponding segments must be
allocated. The code that merges ajoining segments that are part of
the same LV when the metadata is written must also be avoided in
this case. This method of mirroring is unique enough to warrant its
own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two
existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV
(for user created mirrors).
The advantages of performing pvmove in this way is that all of the
LVs affected can be moved together. It is an all-or-nothing approach
that leaves all LV segments on the source PV if the move is aborted.
Additionally, a mirror log can be used (in the future) to provide tracking
of progress; allowing the copy to continue where it left off in the event
there is a deactivation.
2014-06-18 07:59:36 +04:00
" \t [--atomic] \n "
2003-04-30 19:28:17 +04:00
" \t [-A|--autobackup {y|n}] \n "
2003-05-06 16:08:58 +04:00
" \t [-b|--background] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2003-04-30 19:28:17 +04:00
" \t [-d|--debug] \n "
" \t [-h|-?|--help] \n "
" \t [-i|--interval seconds] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2003-04-30 19:28:17 +04:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
2003-09-15 19:01:36 +04:00
" \t [{-n|--name} LogicalVolume] \n "
2003-04-30 19:28:17 +04:00
/* "\t[{-n|--name} LogicalVolume[:LogicalExtent[-LogicalExtent]...]]\n" */
2004-08-18 22:49:29 +04:00
" \t SourcePhysicalVolume[:PhysicalExtent[-PhysicalExtent]...]} \n "
2003-04-30 19:28:17 +04:00
" \t [DestinationPhysicalVolume[:PhysicalExtent[-PhysicalExtent]...]...] \n " ,
2001-09-25 16:49:28 +04:00
2014-06-19 16:40:47 +04:00
abort_ARG , alloc_ARG , atomic_ARG , autobackup_ARG , background_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
interval_ARG , name_ARG , noudevsync_ARG , reportformat_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
2015-05-09 02:59:18 +03:00
xx ( lvpoll ,
" Continue already initiated poll operation on a logical volume " ,
0 ,
" \t [--abort] \n "
2015-05-11 16:22:18 +03:00
" \t [-A|--autobackup {y|n}] \n "
2015-05-14 20:33:54 +03:00
" \t [--commandprofile ProfileName] \n "
2015-05-09 02:59:18 +03:00
" \t [-d|--debug] \n "
" \t [-h|-?|--help] \n "
2015-05-14 20:33:54 +03:00
" \t [--handlemissingpvs] \n "
2015-05-09 02:59:18 +03:00
" \t [-i|--interval seconds] \n "
2015-05-14 20:33:54 +03:00
" \t [--polloperation] \n "
2015-05-09 02:59:18 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n " ,
2015-05-11 16:22:18 +03:00
abort_ARG , autobackup_ARG , handlemissingpvs_ARG , interval_ARG , polloperation_ARG ,
2015-05-09 02:59:18 +03:00
test_ARG )
2002-11-18 17:04:08 +03:00
xx ( pvremove ,
" Remove LVM label(s) from physical volume(s) " ,
2016-02-17 00:00:50 +03:00
ENABLE_ALL_DEVS ,
2014-10-18 12:58:23 +04:00
" pvremove \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-f[f]|--force [--force]] \n "
" \t [-h|-?|--help] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-10-18 12:58:23 +04:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t [-y|--yes] \n "
2002-11-18 17:04:08 +03:00
" \t PhysicalVolume [PhysicalVolume...] \n " ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
force_ARG , reportformat_ARG , test_ARG )
2002-11-18 17:04:08 +03:00
2002-12-12 23:55:49 +03:00
xx ( pvs ,
" Display information about physical volumes " ,
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
CACHE_VGMETADATA | PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT | ENABLE_ALL_DEVS | ENABLE_DUPLICATE_DEVS | LOCKD_VG_SH ,
2014-10-18 12:58:23 +04:00
" pvs \n "
2004-06-19 23:27:00 +04:00
" \t [-a|--all] \n "
2009-10-26 17:37:09 +03:00
" \t [--aligned] \n "
2014-07-02 15:16:32 +04:00
" \t [--binary] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2016-06-20 12:57:24 +03:00
" \t [--configreport ReportName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2014-10-18 12:58:23 +04:00
" \t [-h|-?|--help] \n "
2002-12-12 23:55:49 +03:00
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2016-06-15 14:35:27 +03:00
" \t [--logonly] \n "
2008-06-06 23:28:35 +04:00
" \t [--nameprefixes] \n "
" \t [--noheadings] \n "
2002-12-12 23:55:49 +03:00
" \t [--nosuffix] \n "
2015-10-30 17:43:57 +03:00
" \t [-o|--options [+|-|#]Field[,Field]] \n "
2002-12-12 23:55:49 +03:00
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2016-05-02 15:39:32 +03:00
" \t [--reportformat {basic|json}] \n "
2008-06-25 02:48:53 +04:00
" \t [--rows] \n "
2005-04-20 00:58:25 +04:00
" \t [--segments] \n "
2014-05-29 11:38:59 +04:00
" \t [-S|--select Selection] \n "
2002-12-12 23:55:49 +03:00
" \t [--separator Separator] \n "
2006-08-01 18:56:33 +04:00
" \t [--trustcache] \n "
2002-12-12 23:55:49 +03:00
" \t [--unbuffered] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2008-06-25 01:21:04 +04:00
" \t [--unquoted] \n "
2002-12-12 23:55:49 +03:00
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t [PhysicalVolume [PhysicalVolume...]] \n " ,
2006-05-12 23:16:48 +04:00
2016-06-20 12:57:24 +03:00
aligned_ARG , all_ARG , binary_ARG , configreport_ARG , foreign_ARG ,
ignorelockingfailure_ARG , ignoreskippedcluster_ARG , logonly_ARG ,
nameprefixes_ARG , noheadings_ARG , nolocking_ARG , nosuffix_ARG ,
options_ARG , partial_ARG , readonly_ARG , reportformat_ARG , rows_ARG ,
segments_ARG , select_ARG , separator_ARG , shared_ARG , sort_ARG ,
trustcache_ARG , unbuffered_ARG , units_ARG , unquoted_ARG )
2002-12-12 23:55:49 +03:00
2001-09-25 16:49:28 +04:00
xx ( pvscan ,
" List all physical volumes " ,
2016-01-29 01:40:26 +03:00
PERMITTED_READ_ONLY | LOCKD_VG_SH | NO_LVMETAD_AUTOSCAN ,
2014-10-18 12:58:23 +04:00
" pvscan \n "
2013-09-03 18:06:16 +04:00
" \t [-b|--background] \n "
2014-10-23 00:43:42 +04:00
" \t [--cache [-a|--activate ay] [ DevicePath | -j|--major major --minor minor]...] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t {-e|--exported | -n|--novolumegroup} \n "
" \t [-h|-?|--help] \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-10-18 12:58:23 +04:00
" \t [-s|--short] \n "
" \t [-u|--uuid] \n "
" \t [-v|--verbose] \n "
2001-12-03 23:23:53 +03:00
" \t [--version] \n " ,
2001-09-25 16:49:28 +04:00
2014-09-29 22:43:11 +04:00
activate_ARG , available_ARG , backgroundfork_ARG , cache_long_ARG ,
2013-09-03 18:06:16 +04:00
exported_ARG , ignorelockingfailure_ARG , major_ARG , minor_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
novolumegroup_ARG , partial_ARG , readonly_ARG , reportformat_ARG ,
short_ARG , uuid_ARG )
2001-09-25 16:49:28 +04:00
2004-09-14 20:42:46 +04:00
xx ( segtypes ,
" List available segment types " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2004-09-14 20:42:46 +04:00
" segtypes \n " )
2015-02-23 20:26:50 +03:00
xx ( systemid ,
" Display the system ID, if any, currently set on this host " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2015-02-23 20:26:50 +03:00
" systemid \n " )
2014-01-30 17:09:15 +04:00
xx ( tags ,
" List tags defined on this host " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2014-01-30 17:09:15 +04:00
" tags \n " )
2001-09-25 16:49:28 +04:00
xx ( vgcfgbackup ,
" Backup volume group configuration(s) " ,
2015-03-05 23:00:44 +03:00
PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT | LOCKD_VG_SH ,
2014-10-18 12:58:23 +04:00
" vgcfgbackup \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-f|--file filename] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2014-10-18 12:58:23 +04:00
" \t [-h|-?|--help] \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-10-18 12:58:23 +04:00
" \t [-v|--verbose] \n "
" \t [--version] \n "
2001-12-20 19:05:14 +03:00
" \t [VolumeGroupName...] \n " ,
2002-11-28 18:27:29 +03:00
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
file_ARG , foreign_ARG , ignorelockingfailure_ARG , partial_ARG , readonly_ARG ,
reportformat_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgcfgrestore ,
" Restore volume group configuration " ,
2008-04-03 01:23:39 +04:00
0 ,
2014-10-18 12:58:23 +04:00
" vgcfgrestore \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-f|--file filename] \n "
2012-11-27 02:45:35 +04:00
" \t [--force] \n "
2014-10-18 12:58:23 +04:00
" \t [-l[l]|--list [--list]] \n "
" \t [-M|--metadatatype 1|2] \n "
" \t [-h|--help] \n "
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
2002-01-16 00:28:04 +03:00
" \t VolumeGroupName " ,
2001-09-25 16:49:28 +04:00
2012-11-27 02:45:35 +04:00
file_ARG , force_long_ARG , list_ARG , metadatatype_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgchange ,
" Change volume group attributes " ,
2014-10-02 01:58:00 +04:00
CACHE_VGMETADATA | PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT ,
2014-10-18 12:58:23 +04:00
" vgchange \n "
" \t [-A|--autobackup {y|n}] \n "
" \t [--alloc AllocationPolicy] \n "
" \t [-P|--partial] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [--detachprofile] \n "
" \t [-h|--help] \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2007-06-18 18:14:33 +04:00
" \t [--ignoremonitoring] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2014-10-18 12:58:23 +04:00
" \t [-K|--ignoreactivationskip] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--metadataprofile ProfileName] \n "
2006-05-12 23:16:48 +04:00
" \t [--monitor {y|n}] \n "
2014-10-18 12:58:23 +04:00
" \t [--[vg]metadatacopies #copies] \n "
2010-01-05 23:56:51 +03:00
" \t [--poll {y|n}] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
2008-12-22 12:00:51 +03:00
" \t [--refresh] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-12-03 12:03:48 +03:00
" \t [-S|--select Selection] \n "
2010-05-06 15:15:55 +04:00
" \t [--sysinit] \n "
2015-03-04 20:15:45 +03:00
" \t [--systemid SystemID] \n "
2014-10-18 12:58:23 +04:00
" \t [-t|--test] \n "
" \t [-u|--uuid] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t {-a|--activate [a|e|l]{y|n} | \n "
" \t [--activationmode {complete|degraded|partial}] \n "
" \t -c|--clustered {y|n} | \n "
" \t -x|--resizeable {y|n} | \n "
" \t -l|--logicalvolume MaxLogicalVolumes | \n "
" \t -p|--maxphysicalvolumes MaxPhysicalVolumes | \n "
" \t -s|--physicalextentsize PhysicalExtentSize[bBsSkKmMgGtTpPeE] | \n "
2004-03-08 20:19:15 +03:00
" \t --addtag Tag | \n "
" \t --deltag Tag} \n "
2001-12-03 23:23:53 +03:00
" \t [VolumeGroupName...] \n " ,
2001-09-25 16:49:28 +04:00
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
activationmode_ARG , addtag_ARG , alloc_ARG , allocation_ARG , autobackup_ARG ,
2014-12-03 12:03:48 +03:00
activate_ARG , available_ARG , clustered_ARG , deltag_ARG , detachprofile_ARG ,
2013-07-11 14:44:36 +04:00
ignoreactivationskip_ARG , ignorelockingfailure_ARG , ignoremonitoring_ARG ,
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
ignoreskippedcluster_ARG , logicalvolume_ARG , maxphysicalvolumes_ARG ,
metadataprofile_ARG , monitor_ARG , noudevsync_ARG , metadatacopies_ARG ,
vgmetadatacopies_ARG , partial_ARG , physicalextentsize_ARG , poll_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
refresh_ARG , reportformat_ARG , resizeable_ARG , resizable_ARG , select_ARG ,
sysinit_ARG , systemid_ARG , test_ARG , uuid_ARG , lockstart_ARG , lockstop_ARG ,
locktype_ARG , lockopt_ARG , force_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgck ,
" Check the consistency of volume group(s) " ,
2015-03-05 23:00:44 +03:00
ALL_VGS_IS_DEFAULT | LOCKD_VG_SH ,
2001-09-25 16:49:28 +04:00
" vgck "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2002-11-29 18:02:57 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [VolumeGroupName...] \n " ,
reportformat_ARG )
2001-09-25 16:49:28 +04:00
2002-11-18 17:04:08 +03:00
xx ( vgconvert ,
" Change volume group metadata format " ,
2008-04-03 01:23:39 +04:00
0 ,
2014-10-18 12:58:23 +04:00
" vgconvert \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [--labelsector sector] \n "
" \t [-M|--metadatatype 1|2] \n "
" \t [--pvmetadatacopies #copies] \n "
" \t [--metadatasize MetadataSize[bBsSkKmMgGtTpPeE]] \n "
" \t [--bootloaderareasize BootLoaderAreaSize[bBsSkKmMgGtTpPeE]] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-10-18 12:58:23 +04:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
2002-11-18 17:04:08 +03:00
" \t VolumeGroupName [VolumeGroupName...] \n " ,
2013-05-28 14:37:22 +04:00
force_ARG , test_ARG , labelsector_ARG , bootloaderareasize_ARG ,
2013-02-15 14:14:26 +04:00
metadatatype_ARG , metadatacopies_ARG , pvmetadatacopies_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
metadatasize_ARG , reportformat_ARG )
2002-11-18 17:04:08 +03:00
2001-09-25 16:49:28 +04:00
xx ( vgcreate ,
" Create a volume group " ,
2016-02-16 23:15:24 +03:00
MUST_USE_ALL_ARGS | ENABLE_ALL_DEVS ,
2014-10-18 12:58:23 +04:00
" vgcreate \n "
" \t [-A|--autobackup {y|n}] \n "
" \t [--addtag Tag] \n "
" \t [--alloc AllocationPolicy] \n "
" \t [-c|--clustered {y|n}] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [-l|--maxlogicalvolumes MaxLogicalVolumes] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--metadataprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-M|--metadatatype 1|2] \n "
" \t [--[vg]metadatacopies #copies] \n "
" \t [-p|--maxphysicalvolumes MaxPhysicalVolumes] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-10-18 12:58:23 +04:00
" \t [-s|--physicalextentsize PhysicalExtentSize[bBsSkKmMgGtTpPeE]] \n "
2015-03-04 20:15:45 +03:00
" \t [--systemid SystemID] \n "
2014-10-18 12:58:23 +04:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t [-y|--yes] \n "
" \t [ PHYSICAL DEVICE OPTIONS ] \n "
2009-10-06 00:22:58 +04:00
" \t VolumeGroupName PhysicalDevicePath [PhysicalDevicePath...] \n " ,
2001-09-25 16:49:28 +04:00
2005-03-22 01:55:12 +03:00
addtag_ARG , alloc_ARG , autobackup_ARG , clustered_ARG , maxlogicalvolumes_ARG ,
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
maxphysicalvolumes_ARG , metadataprofile_ARG , metadatatype_ARG ,
physicalextentsize_ARG , test_ARG , force_ARG , zero_ARG , labelsector_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
metadatasize_ARG , pvmetadatacopies_ARG , reportformat_ARG , metadatacopies_ARG ,
2015-03-04 20:15:45 +03:00
vgmetadatacopies_ARG , dataalignment_ARG , dataalignmentoffset_ARG ,
2015-03-05 23:00:44 +03:00
shared_ARG , systemid_ARG , locktype_ARG , lockopt_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgdisplay ,
" Display volume group information " ,
2015-03-05 23:00:44 +03:00
PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT | LOCKD_VG_SH ,
2014-10-18 12:58:23 +04:00
" vgdisplay \n "
" \t [-A|--activevolumegroups] \n "
" \t [-c|--colon | -s|--short | -v|--verbose] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2014-10-18 12:58:23 +04:00
" \t [-h|--help] \n "
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2002-12-12 23:55:49 +03:00
" \t [--nosuffix] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2016-06-24 15:49:13 +03:00
" \t [--reportformat {basic|json}] \n "
2014-12-12 12:20:15 +03:00
" \t [-S|--select Selection] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2002-12-12 23:55:49 +03:00
" \t [VolumeGroupName [VolumeGroupName...]] \n "
" \n "
" vgdisplay --columns|-C \n "
" \t [--aligned] \n "
2014-12-11 17:16:04 +03:00
" \t [--binary] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2016-06-20 12:57:24 +03:00
" \t [--configreport ReportName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2014-10-18 12:58:23 +04:00
" \t [-h|--help] \n "
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2016-06-15 14:35:27 +03:00
" \t [--logonly] \n "
2002-12-12 23:55:49 +03:00
" \t [--noheadings] \n "
" \t [--nosuffix] \n "
2015-10-30 17:43:57 +03:00
" \t [-o|--options [+|-|#]Field[,Field]] \n "
2002-12-12 23:55:49 +03:00
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-05-29 11:39:11 +04:00
" \t [-S|--select Selection] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2002-12-12 23:55:49 +03:00
" \t [--separator Separator] \n "
" \t [--unbuffered] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2014-10-18 12:58:23 +04:00
" \t [--verbose] \n "
" \t [--version] \n "
2002-12-12 23:55:49 +03:00
" \t [VolumeGroupName [VolumeGroupName...]] \n " ,
2001-09-25 16:49:28 +04:00
2014-12-11 17:16:04 +03:00
activevolumegroups_ARG , aligned_ARG , binary_ARG , colon_ARG , columns_ARG ,
2016-06-20 12:57:24 +03:00
configreport_ARG , foreign_ARG , ignorelockingfailure_ARG ,
ignoreskippedcluster_ARG , logonly_ARG , noheadings_ARG , nosuffix_ARG ,
options_ARG , partial_ARG , readonly_ARG , reportformat_ARG , select_ARG ,
shared_ARG , short_ARG , separator_ARG , sort_ARG , unbuffered_ARG , units_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgexport ,
" Unregister volume group(s) from the system " ,
2015-07-15 17:21:45 +03:00
ALL_VGS_IS_DEFAULT ,
2014-10-18 12:58:23 +04:00
" vgexport \n "
" \t [-a|--all] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-12-12 14:03:34 +03:00
" \t [-S|--select Selection] \n "
2014-10-18 12:58:23 +04:00
" \t [-v|--verbose] \n "
" \t [--version] \n "
2001-12-03 23:23:53 +03:00
" \t VolumeGroupName [VolumeGroupName...] \n " ,
2001-09-25 16:49:28 +04:00
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
all_ARG , reportformat_ARG , select_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgextend ,
" Add physical volumes to a volume group " ,
2016-02-16 23:15:24 +03:00
MUST_USE_ALL_ARGS | ENABLE_ALL_DEVS ,
2001-09-25 16:49:28 +04:00
" vgextend \n "
2002-11-29 18:02:57 +03:00
" \t [-A|--autobackup y|n] \n "
2010-10-13 14:34:31 +04:00
" \t [--restoremissing] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
2010-07-07 23:14:57 +04:00
" \t [-f|--force] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|--help] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2013-05-14 21:45:37 +04:00
" \t [-y|--yes] \n "
2014-10-18 12:58:23 +04:00
" \t [ PHYSICAL DEVICE OPTIONS ] \n "
2001-12-03 23:23:53 +03:00
" \t VolumeGroupName PhysicalDevicePath [PhysicalDevicePath...] \n " ,
2001-09-25 16:49:28 +04:00
2009-10-06 00:04:08 +04:00
autobackup_ARG , test_ARG ,
2013-05-14 21:45:37 +04:00
force_ARG , zero_ARG , labelsector_ARG , metadatatype_ARG ,
2009-10-06 00:55:56 +04:00
metadatasize_ARG , pvmetadatacopies_ARG , metadatacopies_ARG ,
2010-10-13 14:34:31 +04:00
metadataignore_ARG , dataalignment_ARG , dataalignmentoffset_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
reportformat_ARG , restoremissing_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgimport ,
" Register exported volume group with system " ,
2016-01-29 01:40:26 +03:00
ALL_VGS_IS_DEFAULT | NO_LVMETAD_AUTOSCAN ,
2014-10-18 12:58:23 +04:00
" vgimport \n "
2002-11-29 18:02:57 +03:00
" \t [-a|--all] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-f|--force] \n "
" \t [-h|--help] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-12-12 14:03:34 +03:00
" \t [-S|--select Selection] \n "
2014-10-18 12:58:23 +04:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t VolumeGroupName... \n " ,
2001-09-25 16:49:28 +04:00
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
all_ARG , force_ARG , reportformat_ARG , select_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
2016-05-25 21:57:33 +03:00
xx ( vgimportclone ,
" Import a VG from cloned PVs " ,
NO_LVMETAD_AUTOSCAN ,
" vgimportclone \n "
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [-i|--import] \n "
" \t [-n|--basevgname] \n "
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t [PhysicalVolumePath...] \n " ,
basevgname_ARG , test_ARG , import_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgmerge ,
" Merge volume groups " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-09-25 16:49:28 +04:00
" vgmerge \n "
2002-11-29 18:02:57 +03:00
" \t [-A|--autobackup y|n] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [-l|--list] \n "
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-09-25 16:49:28 +04:00
" \t DestinationVolumeGroupName SourceVolumeGroupName \n " ,
autobackup_ARG , list_ARG , test_ARG )
xx ( vgmknodes ,
" Create the special files for volume group devices in /dev " ,
2014-10-02 01:58:00 +04:00
ALL_VGS_IS_DEFAULT ,
2001-09-25 16:49:28 +04:00
" vgmknodes \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
2005-04-04 18:44:49 +04:00
" \t [--ignorelockingfailure] \n "
2008-12-22 12:00:51 +03:00
" \t [--refresh] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2002-11-29 18:02:57 +03:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2005-04-04 18:44:49 +04:00
" \t [VolumeGroupName...] \n " ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
ignorelockingfailure_ARG , refresh_ARG , reportformat_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgreduce ,
" Remove physical volume(s) from a volume group " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-09-25 16:49:28 +04:00
" vgreduce \n "
2002-11-29 18:02:57 +03:00
" \t [-a|--all] \n "
" \t [-A|--autobackup y|n] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
2005-12-22 00:21:45 +03:00
" \t [--mirrorsonly] \n "
2003-01-18 00:04:26 +03:00
" \t [--removemissing] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2008-09-19 10:42:00 +04:00
" \t [-f|--force] \n "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-09-25 16:49:28 +04:00
" \t VolumeGroupName \n "
" \t [PhysicalVolumePath...] \n " ,
2008-09-19 11:18:03 +04:00
all_ARG , autobackup_ARG , force_ARG , mirrorsonly_ARG , removemissing_ARG ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
reportformat_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgremove ,
" Remove volume group(s) " ,
2014-12-12 11:34:50 +03:00
ALL_VGS_IS_DEFAULT , /* all VGs only with select */
2001-09-25 16:49:28 +04:00
" vgremove \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
2007-08-28 20:14:49 +04:00
" \t [-f|--force] \n "
2002-11-29 18:02:57 +03:00
" \t [-h|--help] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2014-12-12 11:34:50 +03:00
" \t [-S|--select Selection] \n "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-11-28 21:03:11 +03:00
" \t VolumeGroupName [VolumeGroupName...] \n " ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
force_ARG , noudevsync_ARG , reportformat_ARG , select_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgrename ,
" Rename a volume group " ,
2015-12-01 23:09:01 +03:00
ALLOW_UUID_AS_NAME | REQUIRES_FULL_LABEL_SCAN ,
2001-09-25 16:49:28 +04:00
" vgrename \n "
2002-11-29 18:02:57 +03:00
" \t [-A|--autobackup y|n] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n "
2001-12-03 23:23:53 +03:00
" \t OldVolumeGroupPath NewVolumeGroupPath | \n "
2001-09-25 16:49:28 +04:00
" \t OldVolumeGroupName NewVolumeGroupName \n " ,
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
autobackup_ARG , force_ARG , reportformat_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
2002-12-12 23:55:49 +03:00
xx ( vgs ,
" Display information about volume groups " ,
2015-03-05 23:00:44 +03:00
PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT | LOCKD_VG_SH ,
2014-10-18 12:58:23 +04:00
" vgs \n "
2002-12-12 23:55:49 +03:00
" \t [--aligned] \n "
2014-07-02 15:16:32 +04:00
" \t [--binary] \n "
2005-06-03 18:49:51 +04:00
" \t [-a|--all] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2016-06-20 12:57:24 +03:00
" \t [--configreport ReportName] \n "
2002-12-12 23:55:49 +03:00
" \t [-d|--debug] \n "
2015-02-24 02:41:38 +03:00
" \t [--foreign] \n "
2002-12-12 23:55:49 +03:00
" \t [-h|--help] \n "
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \n "
2016-06-15 14:35:27 +03:00
" \t [--logonly] \n "
2008-06-06 23:28:35 +04:00
" \t [--nameprefixes] \n "
2002-12-12 23:55:49 +03:00
" \t [--noheadings] \n "
" \t [--nosuffix] \n "
2015-10-30 17:43:57 +03:00
" \t [-o|--options [+|-|#]Field[,Field]] \n "
2002-12-12 23:55:49 +03:00
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2016-05-02 15:39:32 +03:00
" \t [--reportformat {basic|json}] \n "
2008-06-25 02:48:53 +04:00
" \t [--rows] \n "
2014-05-29 11:38:59 +04:00
" \t [-S|--select Selection] \n "
2002-12-12 23:55:49 +03:00
" \t [--separator Separator] \n "
2006-08-01 18:56:33 +04:00
" \t [--trustcache] \n "
2002-12-12 23:55:49 +03:00
" \t [--unbuffered] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2008-06-25 01:21:04 +04:00
" \t [--unquoted] \n "
2002-12-12 23:55:49 +03:00
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t [VolumeGroupName [VolumeGroupName...]] \n " ,
2006-05-12 23:16:48 +04:00
2016-06-20 12:57:24 +03:00
aligned_ARG , all_ARG , binary_ARG , configreport_ARG , foreign_ARG ,
ignorelockingfailure_ARG , ignoreskippedcluster_ARG , logonly_ARG ,
nameprefixes_ARG , noheadings_ARG , nolocking_ARG , nosuffix_ARG ,
options_ARG , partial_ARG , readonly_ARG , reportformat_ARG , rows_ARG ,
select_ARG , separator_ARG , shared_ARG , sort_ARG , trustcache_ARG ,
unbuffered_ARG , units_ARG , unquoted_ARG )
2002-12-12 23:55:49 +03:00
2001-09-25 16:49:28 +04:00
xx ( vgscan ,
" Search for all volume groups " ,
2016-01-29 01:40:26 +03:00
PERMITTED_READ_ONLY | ALL_VGS_IS_DEFAULT | LOCKD_VG_SH | NO_LVMETAD_AUTOSCAN ,
2001-09-25 16:49:28 +04:00
" vgscan "
2012-03-27 15:04:46 +04:00
" \t [--cache] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2002-11-29 18:02:57 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2003-11-14 17:03:48 +03:00
" \t [--mknodes] \n "
2016-03-07 19:50:45 +03:00
" \t [--notifydbus] \n "
2014-10-18 12:58:23 +04:00
" \t [-P|--partial] \n "
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
" \t [--reportformat {basic|json}] \n "
2006-05-12 23:16:48 +04:00
" \t [-v|--verbose] \n "
2014-10-18 12:58:23 +04:00
" \t [--version] \n " ,
2002-11-28 18:27:29 +03:00
commands: recognize --reportformat option for other commands
Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.
2016-05-17 14:32:56 +03:00
cache_long_ARG , ignorelockingfailure_ARG , mknodes_ARG , notifydbus_ARG ,
partial_ARG , reportformat_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgsplit ,
2008-01-22 05:48:53 +03:00
" Move physical volumes into a new or existing volume group " ,
2008-04-03 01:23:39 +04:00
0 ,
2014-10-18 12:58:23 +04:00
" vgsplit \n "
" \t [-A|--autobackup {y|n}] \n "
" \t [--alloc AllocationPolicy] \n "
" \t [-c|--clustered {y|n}] \n "
config: differentiate command and metadata profiles and consolidate profile handling code
- When defining configuration source, the code now uses separate
CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers
(before, it was just CONFIG_PROFILE that did not make the
difference between the two). This helps when checking the
configuration if it contains correct set of options which
are all in either command-profilable or metadata-profilable
group without mixing these groups together - so it's a firm
distinction. The "command profile" can't contain
"metadata profile" and vice versa! This is strictly checked
and if the settings are mixed, such profile is rejected and
it's not used. So in the end, the CONFIG_PROFILE_COMMAND
set of options and CONFIG_PROFILE_METADATA are mutually exclusive
sets.
- Marking configuration with one or the other marker will also
determine the way these configuration sources are positioned
in the configuration cascade which is now:
CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES
- Marking configuration with one or the other marker will also make
it possible to issue a command context refresh (will be probably
a part of a future patch) if needed for settings in global profile
set. For settings in metadata profile set this is impossible since
we can't refresh cmd context in the middle of reading VG/LV metadata
and for each VG/LV separately because each VG/LV can have a different
metadata profile assinged and it's not possible to change these
settings at this level.
- When command profile is incorrect, it's rejected *and also* the
command exits immediately - the profile *must* be correct for the
command that was run with a profile to be executed. Before this
patch, when the profile was found incorrect, there was just the
warning message and the command continued without profile applied.
But it's more correct to exit immediately in this case.
- When metadata profile is incorrect, we reject it during command
runtime (as we know the profile name from metadata and not early
from command line as it is in case of command profiles) and we
*do continue* with the command as we're in the middle of operation.
Also, the metadata profile is applied directly and on the fly on
find_config_tree_* fn call and even if the metadata profile is
found incorrect, we still need to return the non-profiled value
as found in the other configuration provided or default value.
To exit immediately even in this case, we'd need to refactor
existing find_config_tree_* fns so they can return error. Currently,
these fns return only config values (which end up with default
values in the end if the config is not found).
- To check the profile validity before use to be sure it's correct,
one can use :
lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate
(the --commandprofile/--metadataprofile for dumpconfig will come
as part of the subsequent patch)
- This patch also adds a reference to --commandprofile and
--metadataprofile in the cmd help string (which was missing before
for the --profile for some commands). We do not mention --profile
now as people should use --commandprofile or --metadataprofile
directly. However, the --profile is still supported for backward
compatibility and it's translated as:
--profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange
(as these commands are able to attach profile to metadata)
--profile == --commandprofile for all the other commands
(--metadataprofile is not allowed there as it makes no sense)
- This patch also contains some cleanups to make the code handling
the profiles more readable...
2014-05-20 16:13:10 +04:00
" \t [--commandprofile ProfileName] \n "
2014-10-18 12:58:23 +04:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [-l|--maxlogicalvolumes MaxLogicalVolumes] \n "
" \t [-M|--metadatatype 1|2] \n "
" \t [--[vg]metadatacopies #copies] \n "
2008-04-09 17:47:13 +04:00
" \t [-n|--name LogicalVolumeName] \n "
2014-10-18 12:58:23 +04:00
" \t [-p|--maxphysicalvolumes MaxPhysicalVolumes] \n "
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
" \t [--version] \n "
" \t SourceVolumeGroupName DestinationVolumeGroupName \n "
2008-04-09 17:47:13 +04:00
" \t [PhysicalVolumePath...] \n " ,
2001-09-25 16:49:28 +04:00
2008-01-16 20:14:56 +03:00
alloc_ARG , autobackup_ARG , clustered_ARG ,
2008-01-15 00:07:58 +03:00
maxlogicalvolumes_ARG , maxphysicalvolumes_ARG ,
2010-06-29 00:39:24 +04:00
metadatatype_ARG , vgmetadatacopies_ARG , name_ARG , test_ARG )
2002-01-17 19:39:24 +03:00
xx ( version ,
" Display software and driver version information " ,
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
PERMITTED_READ_ONLY | NO_METADATA_PROCESSING ,
2014-10-18 12:58:23 +04:00
" version \n " )
