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 .
2013-02-05 14:26:27 +04:00
* Copyright ( C ) 2004 - 2013 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 ,
* Inc . , 59 Temple Place , Suite 330 , Boston , MA 02111 - 1307 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 "
" [-d|--debug] " " [-h|--help] " " [-n|--nofsck] " " \n "
" \t {[-l|--extents] [+|-]LogicalExtentsNumber | " " \n "
2009-07-06 23:13:26 +04:00
" \t [-L|--size] [+|-]LogicalVolumeSize[bBsSkKmMgGtTpPeE]} " " \n "
2002-11-18 17:04:08 +03:00
" \t [-t|--test] " " \n "
" \t [-v|--verbose] " " \n "
" \t [--version] " " \n "
" \t LogicalVolumePath " " \n " ,
extents_ARG , size_ARG , nofsck_ARG , test_ARG )
* * * * * * * * */
2013-09-18 04:09:15 +04:00
xx ( devtypes ,
" Display recognised built-in block device types " ,
PERMITTED_READ_ONLY ,
" devtypes " " \n "
" \t [--aligned] \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 "
" \t [-o|--options [+]Field[,Field]] \n "
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
" \t [--rows] \n "
" \t [--separator Separator] \n "
" \t [--unbuffered] \n "
" \t [--unquoted] \n "
" \t [-v|--verbose] \n "
" \t [--version] " " \n " ,
aligned_ARG , nameprefixes_ARG ,
noheadings_ARG , nosuffix_ARG , options_ARG ,
rows_ARG , separator_ARG , sort_ARG ,
unbuffered_ARG , unquoted_ARG )
2003-10-16 00:17:19 +04:00
xx ( dumpconfig ,
2013-03-05 20:48:29 +04:00
" Dump configuration " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2013-03-05 20:48:29 +04:00
" dumpconfig \n "
" \t [-f|--file filename] \n "
2014-05-20 16:45:20 +04:00
" \t [--type {current|default|diff|missing|new|profilable|profilable-command|profilable-metadata} \n "
2013-07-19 22:24:54 +04:00
" \t [--atversion version]] \n "
2013-03-06 12:35:33 +04:00
" \t [--ignoreadvanced] \n "
" \t [--ignoreunsupported] \n "
2014-05-20 16:45:20 +04:00
" \t [--config ConfigurationString] \n "
" \t [--commandprofile ProfileName] \n "
" \t [--profile ProfileName] \n "
" \t [--metadataprofile ProfileName] \n "
2013-07-08 17:34:27 +04:00
" \t [--mergedconfig] \n "
2013-03-05 20:48:29 +04:00
" \t [--validate] \n "
2013-07-19 22:24:54 +04:00
" \t [--withcomments] \n "
" \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 ,
2014-05-20 16:45:20 +04:00
ignoreunsupported_ARG , mergedconfig_ARG , metadataprofile_ARG ,
validate_ARG , withcomments_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 " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2004-09-14 20:42:46 +04:00
" formats \n " )
2001-09-25 16:49:28 +04:00
xx ( help ,
" Display help for commands " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2001-12-03 23:23:53 +03: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
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 "
2002-11-29 18:02:57 +03:00
" \t [-A|--autobackup y|n] \n "
2012-06-27 18:43:20 +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 "
2002-11-29 18:02:57 +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-29 18:02:57 +03:00
" \t [-d|--debug] \n "
2004-03-08 20:19:15 +03:00
" \t [--deltag Tag] \n "
2013-06-25 14:33:06 +04:00
" \t [--detachprofile] \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 "
" \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 "
2003-04-02 23:14:43 +04:00
" \t [-M|--persistent y|n] [--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-29 18:02:57 +03:00
" \t [-P|--partial] " " \n "
" \t [-p|--permission r|rw] \n "
2013-07-19 22:24:54 +04:00
" \t [--[raid]minrecoveryrate Rate] \n "
" \t [--[raid]maxrecoveryrate Rate] \n "
" \t [--[raid]syncaction {check|repair} \n "
" \t [--[raid]writebehind IOCount] \n "
2013-07-19 23:37:43 +04:00
" \t [--[raid]writemostly PhysicalVolume[:{t|n|y}]] \n "
2007-11-09 19:51:54 +03:00
" \t [-r|--readahead ReadAheadSectors|auto|none] \n "
2004-03-27 00:24:03 +03:00
" \t [--refresh] \n "
2006-10-24 21:19:48 +04:00
" \t [--resync] \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 "
2001-09-25 16:49:28 +04:00
" \t LogicalVolume[Path] [LogicalVolume[Path]...] \n " ,
2013-07-19 22:24:54 +04:00
addtag_ARG , alloc_ARG , autobackup_ARG , activate_ARG , available_ARG ,
contiguous_ARG , deltag_ARG , discards_ARG , detachprofile_ARG , force_ARG ,
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 ,
2014-05-19 18:29:06 +04:00
raidminrecoveryrate_ARG , raidmaxrecoveryrate_ARG , raidsyncaction_ARG ,
raidwritebehind_ARG , raidwritemostly_ARG , readahead_ARG , resync_ARG ,
refresh_ARG , setactivationskip_ARG , syncaction_ARG , sysinit_ARG , test_ARG ,
writebehind_ARG , writemostly_ARG , zero_ARG )
2001-09-25 16:49:28 +04:00
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 "
2010-03-27 01:15:43 +03:00
" [-m|--mirrors Mirrors [{--mirrorlog {disk|core|mirrored}|--corelog}]] \n "
2011-10-07 18:52:26 +04:00
" \t [--type SegmentType] \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 "
2006-10-08 03:04:36 +04:00
" \t [-R|--regionsize MirrorLogRegionSize] \n "
2005-06-06 21:12:08 +04:00
" \t [--alloc AllocationPolicy] \n "
2007-12-22 15:13:29 +03: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 "
2005-06-06 21:12:08 +04:00
" \t [-d|--debug] \n "
2009-06-30 22:39:31 +04:00
" \t [-f|--force] \n "
2005-06-06 21:12:08 +04:00
" \t [-h|-?|--help] \n "
2007-12-22 15:13:29 +03:00
" \t [-i|--interval seconds] \n "
2010-04-13 05:54:32 +04:00
" \t [--stripes Stripes [-I|--stripesize StripeSize]] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
2005-06-06 21:12:08 +04:00
" \t [-v|--verbose] \n "
2009-06-30 22:39:31 +04:00
" \t [-y|--yes] \n "
2005-06-06 21:12:08 +04:00
" \t [--version] " " \n "
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 "
2011-08-18 23:38:26 +04:00
" [--splitmirrors Images --trackchanges] \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
" [--splitmirrors Images --name SplitLogicalVolumeName] \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 "
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 "
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-12-04 06:09:37 +04:00
" \t [-d|--debug] \n "
" \t [-h|-?|--help] \n "
" \t [--noudevsync] \n "
" \t [-v|--verbose] \n "
" \t [--version] " " \n "
" \t SnapshotLogicalVolume[Path] \n \n "
2006-04-06 00:43:23 +04:00
" lvconvert "
" [-s|--snapshot] \n "
" \t [-c|--chunksize] \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 "
2006-04-06 00:43:23 +04:00
" \t [-d|--debug] \n "
" \t [-h|-?|--help] \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
2006-04-06 00:43:23 +04:00
" \t [-v|--verbose] \n "
" \t [-Z|--zero {y|n}] \n "
" \t [--version] " " \n "
2010-01-13 04:45:15 +03:00
" \t OriginalLogicalVolume[Path] SnapshotLogicalVolume[Path] \n \n "
" lvconvert "
" --merge \n "
" \t [-b|--background] \n "
" \t [-i|--interval seconds] \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 "
2010-01-13 04:45:15 +03:00
" \t [-d|--debug] \n "
" \t [-h|-?|--help] \n "
" \t [-v|--verbose] \n "
2012-05-09 16:17:06 +04:00
" \t LogicalVolume[Path] \n \n "
" lvconvert "
" --thinpool ThinPoolLogicalVolume[Path] \n "
" \t [--chunksize size] \n "
2012-05-14 15:57:30 +04:00
" \t [--discards {ignore|nopassdown|passdown}] \n "
2012-11-19 16:37:57 +04:00
" \t [--poolmetadata ThinMetadataLogicalVolume[Path] | \n "
" \t [--poolmetadatasize size] \n "
2013-06-25 15:35:12 +04:00
" \t [--poolmetadataspare {y|n}] \n "
2013-07-19 22:24:54 +04:00
" \t [-r|--readahead ReadAheadSectors|auto|none] \n "
2012-11-19 16:37:57 +04:00
" \t [--stripes Stripes [-I|--stripesize StripeSize]]] \n "
2013-02-05 14:26:27 +04:00
" \t [-T|--thin ExternalLogicalVolume[Path] \n "
" \t [--originname NewExternalOriginVolumeName]] \n "
2012-05-14 15:57:30 +04:00
" \t [-Z|--zero {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-02-12 19:51:42 +04:00
" \t [-d|--debug] [-h|-?|--help] [-v|--verbose] \n \n "
2005-06-06 21:12:08 +04:00
2014-02-12 19:51:42 +04:00
" lvconvert "
2014-03-28 12:10:30 +04:00
" --type cache-pool \n "
2014-02-12 19:51:42 +04:00
" \t [--cachemode CacheMode] \n "
" \t [--chunksize size] \n "
" \t [--poolmetadata CacheMetadataLogicalVolume[Path] | \n "
" \t [--poolmetadatasize size] \n "
" \t [--poolmetadataspare {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-02-12 19:55:35 +04:00
" \t CacheDataLogicalVolume[Path] \n \n "
2014-02-12 19:51:42 +04:00
2014-02-12 19:55:35 +04:00
" lvconvert "
" --type cache \n "
" \t --cachepool CachePoolLogicalVolume[Path] \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-02-12 19:55:35 +04:00
" \t LogicalVolume[Path] \n \n " ,
alloc_ARG , background_ARG , cachemode_ARG , cachepool_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 ,
repair_ARG , replace_ARG , snapshot_ARG , splitmirrors_ARG , splitsnapshot_ARG ,
2013-12-04 06:09:37 +04:00
stripes_long_ARG , stripesize_ARG , test_ARG , thin_ARG , thinpool_ARG ,
trackchanges_ARG , type_ARG , use_policies_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 ,
2002-02-11 14:43:17 +03: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-02-04 21:57:08 +04:00
" \t [--cachemode CacheMode] \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 "
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 "
" \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 "
2003-04-02 23:14:43 +04:00
" \t [-M|--persistent {y|n}] [--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 "
2010-03-27 01:15:43 +03:00
" \t [-m|--mirrors Mirrors [--nosync] [{--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 "
2013-07-19 22:24:54 +04:00
" \t [--[raid]minrecoveryrate Rate] \n "
" \t [--[raid]maxrecoveryrate Rate] \n "
2007-11-09 19:51:54 +03:00
" \t [-r|--readahead ReadAheadSectors|auto|none] \n "
2005-06-01 20:51:55 +04:00
" \t [-R|--regionsize MirrorLogRegionSize] \n "
2012-08-09 14:20:47 +04:00
" \t [-T|--thin [-c|--chunksize ChunkSize] \n "
" \t [--discards {ignore|nopassdown|passdown}] \n "
" \t [--poolmetadatasize MetadataSize[bBsSkKmMgG]]] \n "
2013-06-25 15:34:31 +04:00
" \t [--poolmetadataspare {y|n}] \n "
2012-08-09 14:20:47 +04:00
" \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
2009-05-27 20:30:29 +04:00
" lvcreate \n "
" \t { {-s|--snapshot} OriginalLogicalVolume[Path] | \n "
2011-08-17 19:15:36 +04:00
" \t [-s|--snapshot] VolumeGroupName[Path] -V|--virtualsize VirtualSize} \n "
2011-09-06 04:26:42 +04:00
" \t {-T|--thin} VolumeGroupName[Path][/PoolLogicalVolume] \n "
" \t -V|--virtualsize VirtualSize} \n "
2002-11-28 18:27:29 +03:00
" \t [-c|--chunksize] \n "
" \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 "
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 "
2013-07-10 16:06:50 +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 "
2013-06-11 15:45:49 +04:00
" \t [--poolmetadatasize MetadataVolumeSize[bBsSkKmMgG]] \n "
2003-04-02 23:14:43 +04:00
" \t [-M|--persistent {y|n}] [--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 "
2002-11-28 18:27:29 +03:00
" \t [-t|--test] \n "
2012-08-07 23:10:06 +04:00
" \t [--thinpool ThinPoolLogicalVolume[Path]] \n "
2002-11-28 18:27:29 +03:00
" \t [-v|--verbose] \n "
" \t [--version] \n "
2009-05-27 20:30:29 +04:00
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-02-04 21:57:08 +04:00
cachemode_ARG , chunksize_ARG , contiguous_ARG , corelog_ARG , discards_ARG ,
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 ,
noudevsync_ARG , permission_ARG , persistent_ARG , poolmetadatasize_ARG ,
poolmetadataspare_ARG , raidminrecoveryrate_ARG , raidmaxrecoveryrate_ARG ,
readahead_ARG , regionsize_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 " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
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 "
" \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 "
2002-11-29 18:02:57 +03:00
" \t [-P|--partial] " " \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \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 "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n "
" \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 "
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-12-12 23:55:49 +03:00
" \t [-d|--debug] \n "
" \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 [--noheadings] \n "
" \t [--nosuffix] \n "
" \t [-o|--options [+]Field[,Field]] \n "
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
2014-05-29 11:39:11 +04:00
" \t [-S|--select Selection] \n "
2002-12-12 23:55:49 +03:00
" \t [-P|--partial] " " \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \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 "
" \t [--version] " " \n "
" \t [LogicalVolume[Path] [LogicalVolume[Path]...]] \n " ,
2001-09-25 16:49:28 +04:00
2013-10-02 00:20:10 +04:00
aligned_ARG , all_ARG , colon_ARG , columns_ARG , ignorelockingfailure_ARG ,
ignoreskippedcluster_ARG , maps_ARG , noheadings_ARG , nosuffix_ARG ,
2014-04-18 05:46:34 +04:00
options_ARG , sort_ARG , partial_ARG , readonly_ARG , segments_ARG ,
2014-05-29 11:39:11 +04:00
select_ARG , separator_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 "
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 "
2002-12-12 23:55:49 +03: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 ,
resizefs_ARG , size_ARG , stripes_ARG ,
2010-10-15 20:28:14 +04:00
stripesize_ARG , test_ARG , type_ARG , use_policies_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 "
" \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
xx ( lvmdiskscan ,
" List devices that may be used as physical volumes " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
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 "
2002-12-12 23:55:49 +03: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 "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n "
2001-09-25 16:49:28 +04:00
" \t [LogFilePath] \n " )
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 "
2002-12-12 23:55:49 +03: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 "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2002-12-12 23:55:49 +03: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 ,
2013-05-14 21:45:37 +04:00
resizefs_ARG , size_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
xx ( lvremove ,
" Remove logical volume(s) from the system " ,
2008-04-03 01:23:39 +04:00
0 ,
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 "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n "
2001-09-25 16:49:28 +04:00
" \t LogicalVolume[Path] [LogicalVolume[Path]...] \n " ,
2009-08-04 19:53:04 +04:00
autobackup_ARG , force_ARG , noudevsync_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 "
2001-12-03 23:23:53 +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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
2002-11-29 18:02:57 +03:00
" \t [-h|-?|--help] " " \n "
2009-08-04 19:53:04 +04:00
" \t [--noudevsync] \n "
2001-12-03 23:23:53 +03:00
" \t [-t|--test] " " \n "
" \t [-v|--verbose] " " \n "
" \t [--version] " " \n "
" \t { OldLogicalVolumePath NewLogicalVolumePath | " " \n "
" \t VolumeGroupName OldLogicalVolumeName NewLogicalVolumeName } \n " ,
2001-09-25 16:49:28 +04:00
2009-08-04 19:53:04 +04:00
autobackup_ARG , noudevsync_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 "
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 "
2002-12-12 23:55:49 +03: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 ,
2013-06-11 15:45:49 +04:00
noudevsync_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 " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2002-12-12 23:55:49 +03: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 "
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-12-12 23:55:49 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \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 "
" \t [-o|--options [+]Field[,Field]] \n "
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
" \t [-P|--partial] " " \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \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 "
" \t [--version] " " \n "
" \t [LogicalVolume[Path] [LogicalVolume[Path]...]] \n " ,
2006-05-12 23:16:48 +04:00
2013-10-02 00:20:10 +04:00
aligned_ARG , all_ARG , ignorelockingfailure_ARG , ignoreskippedcluster_ARG ,
2014-05-29 11:38:59 +04:00
nameprefixes_ARG , noheadings_ARG , nolocking_ARG , nosuffix_ARG , options_ARG ,
partial_ARG , readonly_ARG , rows_ARG , segments_ARG , select_ARG ,
separator_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 " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2001-12-03 23:23:53 +03:00
" lvscan " " \n "
2005-10-17 20:41:38 +04:00
" \t [-a|--all] \n "
2001-12-03 23:23:53 +03:00
" \t [-b|--blockdevice] " " \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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
2002-11-29 18:02:57 +03:00
" \t [-h|-?|--help] " " \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2002-04-30 21:12:37 +04:00
" \t [-P|--partial] " " \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2001-12-03 23:23:53 +03:00
" \t [-v|--verbose] " " \n "
" \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 ,
readonly_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 "
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 "
2010-06-29 00:33:58 +04:00
" \t [--metadataignore 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 "
2004-01-13 21:42:05 +03: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 ,
2010-07-07 23:14:57 +04:00
addtag_ARG , force_ARG , metadataignore_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 ,
2005-10-31 05:37:29 +03: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 "
2005-10-31 05:37:29 +03:00
" \t [-d|--debug] " " \n "
" \t [-h|-?|--help] " " \n "
2009-07-06 23:13:26 +04:00
" \t [--setphysicalvolumesize PhysicalVolumeSize[bBsSkKmMgGtTpPeE] " " \n "
2005-10-31 05:37:29 +03:00
" \t [-t|--test] " " \n "
" \t [-v|--verbose] " " \n "
" \t [--version] " " \n "
" \t PhysicalVolume [PhysicalVolume...] \n " ,
physicalvolumesize_ARG , test_ARG )
2007-03-31 01:00:26 +04:00
xx ( pvck ,
" Check the consistency of physical volume(s) " ,
2008-04-03 01:23:39 +04:00
0 ,
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 "
2007-04-26 00:03:16 +04:00
" \t [--labelsector sector] " " \n "
2007-03-31 01:00:26 +04:00
" \t [-v|--verbose] \n "
" \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 " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-12-03 23:23:53 +03: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 "
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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
" \t [-f[f]|--force [--force]] " " \n "
2002-11-29 18:02:57 +03:00
" \t [-h|-?|--help] " " \n "
2002-11-18 17:04:08 +03:00
" \t [--labelsector sector] " " \n "
" \t [-M|--metadatatype 1|2] " " \n "
2009-10-06 00:55:56 +04:00
" \t [--pvmetadatacopies #copies] " " \n "
2013-05-28 14:37:22 +04:00
" \t [--bootloaderareasize BootLoaderAreaSize[bBsSkKmMgGtTpPeE]] " " \n "
2013-07-19 22:24:54 +04:00
" \t [--metadatasize MetadataSize[bBsSkKmMgGtTpPeE]] " " \n "
2009-07-06 23:13:26 +04:00
" \t [--dataalignment Alignment[bBsSkKmMgGtTpPeE]] " " \n "
2009-07-30 21:45:28 +04:00
" \t [--dataalignmentoffset AlignmentOffset[bBsSkKmMgGtTpPeE]] " " \n "
2009-07-06 23:13:26 +04:00
" \t [--setphysicalvolumesize PhysicalVolumeSize[bBsSkKmMgGtTpPeE] " " \n "
2001-12-03 23:23:53 +03:00
" \t [-t|--test] " " \n "
2002-01-16 21:10:08 +03:00
" \t [-u|--uuid uuid] " " \n "
2001-12-03 23:23:53 +03:00
" \t [-v|--verbose] " " \n "
2002-11-18 17:04:08 +03:00
" \t [-y|--yes] " " \n "
2005-01-05 20:25:25 +03:00
" \t [-Z|--zero {y|n}] \n "
2001-12-03 23:23:53 +03:00
" \t [--version] " " \n "
" \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 ,
2013-05-14 21:45:37 +04:00
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 ,
2001-12-03 23:23:53 +03: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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
" \t [-E|--physicalextent] " " \n "
2002-11-29 18:02:57 +03:00
" \t [-h|-?|--help] " " \n "
2001-12-03 23:23:53 +03:00
" \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 "
" \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) " ,
2010-10-25 15:20:54 +04:00
CACHE_VGMETADATA | PERMITTED_READ_ONLY ,
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 "
" \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 "
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 "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n "
" \t [PhysicalVolumePath [PhysicalVolumePath...]] \n "
" \n "
" pvdisplay --columns|-C \n "
" \t [--aligned] \n "
2005-03-21 17:47:36 +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 "
2002-12-12 23:55:49 +03:00
" \t [-d|--debug] \n "
" \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 [--noheadings] \n "
" \t [--nosuffix] \n "
" \t [-o|--options [+]Field[,Field]] \n "
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \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 "
" \t [--version] " " \n "
" \t [PhysicalVolumePath [PhysicalVolumePath...]] \n " ,
2001-09-25 16:49:28 +04:00
2005-03-21 17:47:36 +03:00
aligned_ARG , all_ARG , colon_ARG , columns_ARG , ignorelockingfailure_ARG ,
2013-10-02 00:20:10 +04:00
ignoreskippedcluster_ARG , maps_ARG , noheadings_ARG , nosuffix_ARG ,
2014-05-29 11:39:11 +04:00
options_ARG , readonly_ARG , select_ARG , separator_ARG , short_ARG , sort_ARG ,
2014-04-18 05:46:34 +04:00
unbuffered_ARG , units_ARG )
2001-09-25 16:49:28 +04:00
xx ( pvmove ,
" Move extents from one physical volume to another " ,
2008-04-03 01:23:39 +04:00
0 ,
2003-04-30 19:28:17 +04:00
" pvmove " " \n "
2003-05-06 16:08:58 +04:00
" \t [--abort] \n "
2003-04-30 19:28:17 +04:00
" \t [-A|--autobackup {y|n}] \n "
2004-11-16 21:09:32 +03:00
" \t [--alloc AllocationPolicy] \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 "
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
2006-05-12 23:16:48 +04:00
abort_ARG , alloc_ARG , autobackup_ARG , background_ARG ,
2009-08-04 19:53:04 +04:00
interval_ARG , name_ARG , noudevsync_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
2002-11-18 17:04:08 +03:00
xx ( pvremove ,
" Remove LVM label(s) from physical volume(s) " ,
2008-04-03 01:23:39 +04:00
0 ,
2002-11-18 17:04:08 +03: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 "
2002-11-18 17:04:08 +03:00
" \t [-d|--debug] " " \n "
" \t [-f[f]|--force [--force]] " " \n "
2002-11-29 18:02:57 +03:00
" \t [-h|-?|--help] " " \n "
2002-11-18 17:04:08 +03:00
" \t [-t|--test] " " \n "
" \t [-v|--verbose] " " \n "
" \t [--version] " " \n "
2013-05-14 21:45:37 +04:00
" \t [-y|--yes] " " \n "
2002-11-18 17:04:08 +03:00
" \t PhysicalVolume [PhysicalVolume...] \n " ,
2013-05-14 21:45:37 +04:00
force_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 " ,
2010-10-25 15:20:54 +04:00
CACHE_VGMETADATA | PERMITTED_READ_ONLY ,
2002-12-12 23:55:49 +03: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 "
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-12-12 23:55:49 +03:00
" \t [-d|--debug] " " \n "
" \t [-h|-?|--help] " " \n "
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \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 "
" \t [-o|--options [+]Field[,Field]] \n "
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
2006-04-13 21:51:40 +04:00
" \t [-P|--partial] " " \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \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
2013-10-02 00:20:10 +04:00
aligned_ARG , all_ARG , ignorelockingfailure_ARG , ignoreskippedcluster_ARG ,
nameprefixes_ARG , noheadings_ARG , nolocking_ARG , nosuffix_ARG , options_ARG ,
2014-05-29 11:38:59 +04:00
partial_ARG , readonly_ARG , rows_ARG , segments_ARG , select_ARG , separator_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 " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2001-12-03 23:23:53 +03:00
" pvscan " " \n "
2013-09-03 18:06:16 +04:00
" \t [-b|--background] \n "
2013-09-03 11:51:30 +04:00
" \t [--cache [-a|--activate ay] [ DevicePath | --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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
2002-11-29 18:02:57 +03:00
" \t {-e|--exported | -n|--novolumegroup} " " \n "
" \t [-h|-?|--help] " " \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2002-04-30 21:12:37 +04:00
" \t [-P|--partial] " " \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2001-12-03 23:23:53 +03:00
" \t [-s|--short] " " \n "
" \t [-u|--uuid] " " \n "
" \t [-v|--verbose] " " \n "
" \t [--version] \n " ,
2001-09-25 16:49:28 +04:00
2013-09-06 04:43:24 +04:00
activate_ARG , available_ARG , backgroundfork_ARG , cache_ARG ,
2013-09-03 18:06:16 +04:00
exported_ARG , ignorelockingfailure_ARG , major_ARG , minor_ARG ,
2014-04-18 05:46:34 +04:00
novolumegroup_ARG , partial_ARG , readonly_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 " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2004-09-14 20:42:46 +04:00
" segtypes \n " )
2014-01-30 17:09:15 +04:00
xx ( tags ,
" List tags defined on this host " ,
PERMITTED_READ_ONLY ,
" tags \n " )
2001-09-25 16:49:28 +04:00
xx ( vgcfgbackup ,
" Backup volume group configuration(s) " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2001-12-03 23:23:53 +03: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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
2002-01-09 22:16:48 +03:00
" \t [-f|--file filename] " " \n "
2002-11-29 18:02:57 +03:00
" \t [-h|-?|--help] " " \n "
2002-11-28 18:27:29 +03:00
" \t [--ignorelockingfailure] \n "
2002-07-11 18:09:26 +04:00
" \t [-P|--partial] " " \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2001-12-03 23:23:53 +03:00
" \t [-v|--verbose] " " \n "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n "
2001-12-20 19:05:14 +03:00
" \t [VolumeGroupName...] \n " ,
2002-11-28 18:27:29 +03:00
2014-04-18 05:46:34 +04:00
file_ARG , ignorelockingfailure_ARG , partial_ARG , readonly_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgcfgrestore ,
" Restore volume group configuration " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-12-03 23:23:53 +03: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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
2002-01-09 22:16:48 +03:00
" \t [-f|--file filename] " " \n "
2012-11-27 02:45:35 +04:00
" \t [--force] \n "
2001-12-03 23:23:53 +03:00
" \t [-l[l]|--list [--list]] " " \n "
2002-11-18 17:04:08 +03:00
" \t [-M|--metadatatype 1|2] " " \n "
2001-12-03 23:23:53 +03:00
" \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 " ,
2010-10-25 15:20:54 +04:00
CACHE_VGMETADATA | PERMITTED_READ_ONLY ,
2001-12-03 23:23:53 +03:00
" vgchange " " \n "
" \t [-A|--autobackup {y|n}] " " \n "
2004-11-16 21:09:32 +03:00
" \t [--alloc AllocationPolicy] " " \n "
2002-01-29 20:23:33 +03:00
" \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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
2013-06-25 14:33:06 +04:00
" \t [--detachprofile] " " \n "
2001-12-03 23:23:53 +03:00
" \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 "
2013-07-11 14:44:36 +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 "
2010-06-29 00:37:37 +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 "
2010-05-06 15:15:55 +04:00
" \t [--sysinit] \n "
2001-12-03 23:23:53 +03:00
" \t [-t|--test] " " \n "
2004-01-13 21:42:05 +03:00
" \t [-u|--uuid] " " \n "
2001-12-03 23:23:53 +03:00
" \t [-v|--verbose] " " \n "
" \t [--version] " " \n "
2012-06-27 18:21:15 +04:00
" \t {-a|--activate [a|e|l]{y|n} | " " \n "
2005-03-22 01:55:12 +03:00
" \t -c|--clustered {y|n} | " " \n "
2002-01-10 18:09:51 +03:00
" \t -x|--resizeable {y|n} | " " \n "
2004-03-08 20:19:15 +03:00
" \t -l|--logicalvolume MaxLogicalVolumes | " " \n "
2006-08-16 18:41:42 +04:00
" \t -p|--maxphysicalvolumes MaxPhysicalVolumes | " " \n "
2009-07-06 23:13:26 +04:00
" \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
2012-06-27 15:48:31 +04:00
addtag_ARG , alloc_ARG , allocation_ARG , autobackup_ARG , activate_ARG ,
2013-06-25 14:33:06 +04:00
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 ,
refresh_ARG , resizeable_ARG , resizable_ARG , sysinit_ARG , test_ARG , uuid_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgck ,
" Check the consistency of volume group(s) " ,
2008-04-03 01:23:39 +04:00
0 ,
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 "
" \t [-v|--verbose] \n "
2003-04-30 19:28:17 +04:00
" \t [--version] " " \n "
2001-09-25 16:49:28 +04:00
" \t [VolumeGroupName...] \n " )
2002-11-18 17:04:08 +03:00
xx ( vgconvert ,
" Change volume group metadata format " ,
2008-04-03 01:23:39 +04:00
0 ,
2002-11-18 17:04:08 +03: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 "
2002-11-18 17:04:08 +03:00
" \t [-d|--debug] " " \n "
" \t [-h|--help] " " \n "
" \t [--labelsector sector] " " \n "
" \t [-M|--metadatatype 1|2] " " \n "
2009-10-06 00:55:56 +04:00
" \t [--pvmetadatacopies #copies] " " \n "
2009-07-06 23:13:26 +04:00
" \t [--metadatasize MetadataSize[bBsSkKmMgGtTpPeE]] " " \n "
2013-05-28 14:37:22 +04:00
" \t [--bootloaderareasize BootLoaderAreaSize[bBsSkKmMgGtTpPeE]] " " \n "
2002-11-18 17:04:08 +03:00
" \t [-t|--test] " " \n "
" \t [-v|--verbose] " " \n "
" \t [--version] " " \n "
" \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 ,
metadatasize_ARG )
2002-11-18 17:04:08 +03:00
2001-09-25 16:49:28 +04:00
xx ( vgcreate ,
" Create a volume group " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-12-03 23:23:53 +03:00
" vgcreate " " \n "
" \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 "
2007-01-23 16:08:34 +03:00
" \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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
2002-04-24 22:20:51 +04:00
" \t [-h|--help] " " \n "
2001-12-03 23:23:53 +03:00
" \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 "
2002-11-18 17:04:08 +03:00
" \t [-M|--metadatatype 1|2] " " \n "
2010-06-29 00:38:23 +04:00
" \t [--[vg]metadatacopies #copies] " " \n "
2001-12-03 23:23:53 +03:00
" \t [-p|--maxphysicalvolumes MaxPhysicalVolumes] " " \n "
2009-07-06 23:13:26 +04:00
" \t [-s|--physicalextentsize PhysicalExtentSize[bBsSkKmMgGtTpPeE]] " " \n "
2001-12-03 23:23:53 +03:00
" \t [-t|--test] " " \n "
" \t [-v|--verbose] " " \n "
" \t [--version] " " \n "
2013-05-14 21:45:37 +04:00
" \t [-y|--yes] " " \n "
2009-10-06 00:22:58 +04:00
" \t [ PHYSICAL DEVICE OPTIONS ] " " \n "
" \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 ,
metadatasize_ARG , pvmetadatacopies_ARG , metadatacopies_ARG ,
vgmetadatacopies_ARG , dataalignment_ARG , dataalignmentoffset_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgdisplay ,
" Display volume group information " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2001-12-03 23:23:53 +03:00
" vgdisplay " " \n "
2009-10-26 17:37:09 +03:00
" \t [-A|--activevolumegroups] " " \n "
2001-12-03 23:23:53 +03:00
" \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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
" \t [-h|--help] " " \n "
2002-11-18 17:04:08 +03:00
" \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 "
2002-01-30 18:33:12 +03:00
" \t [-P|--partial] " " \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \n "
2009-10-26 17:37:09 +03:00
" \t [--units hHbBsSkKmMgGtTpPeE] \n "
2002-01-30 18:33:12 +03:00
" \t [--version] " " \n "
2002-12-12 23:55:49 +03:00
" \t [VolumeGroupName [VolumeGroupName...]] \n "
" \n "
" vgdisplay --columns|-C \n "
" \t [--aligned] \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-12-12 23:55:49 +03:00
" \t [-d|--debug] " " \n "
" \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 [--noheadings] \n "
" \t [--nosuffix] \n "
" \t [-o|--options [+]Field[,Field]] \n "
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
" \t [-P|--partial] " " \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 [--verbose] " " \n "
" \t [--version] " " \n "
" \t [VolumeGroupName [VolumeGroupName...]] \n " ,
2001-09-25 16:49:28 +04:00
2009-10-26 17:37:09 +03:00
activevolumegroups_ARG , aligned_ARG , colon_ARG , columns_ARG ,
2013-10-02 00:20:10 +04:00
ignorelockingfailure_ARG , ignoreskippedcluster_ARG , noheadings_ARG ,
2014-05-29 11:39:11 +04:00
nosuffix_ARG , options_ARG , partial_ARG , readonly_ARG , select_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 " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-12-03 23:23:53 +03: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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
" \t [-h|--help] " " \n "
" \t [-v|--verbose] " " \n "
" \t [--version] " " \n "
" \t VolumeGroupName [VolumeGroupName...] \n " ,
2001-09-25 16:49:28 +04:00
2001-11-28 21:03:11 +03:00
all_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgextend ,
" Add physical volumes to a volume group " ,
2008-04-03 01:23:39 +04:00
0 ,
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 "
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n "
2013-05-14 21:45:37 +04:00
" \t [-y|--yes] \n "
2009-10-06 00:22:58 +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 ,
restoremissing_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgimport ,
" Register exported volume group with system " ,
2008-04-03 01:23:39 +04:00
0 ,
2001-12-03 23:23:53 +03: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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
" \t [-f|--force] " " \n "
" \t [-h|--help] " " \n "
" \t [-t|--test] " " \n "
" \t [-v|--verbose] " " \n "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n "
2002-01-29 22:19:37 +03:00
" \t VolumeGroupName... " " \n " ,
2001-09-25 16:49:28 +04:00
2002-01-29 22:19:37 +03:00
all_ARG , force_ARG , test_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 "
2002-12-12 23:55:49 +03: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 " ,
2008-04-03 01:23:39 +04:00
0 ,
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 "
2002-11-29 18:02:57 +03:00
" \t [-v|--verbose] \n "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n "
2005-04-04 18:44:49 +04:00
" \t [VolumeGroupName...] \n " ,
2008-12-22 12:00:51 +03:00
ignorelockingfailure_ARG , refresh_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 "
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 "
2002-12-12 23:55:49 +03: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 ,
test_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgremove ,
" Remove volume group(s) " ,
2008-04-03 01:23:39 +04:00
0 ,
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 "
2002-11-29 18:02:57 +03:00
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n "
2001-11-28 21:03:11 +03:00
" \t VolumeGroupName [VolumeGroupName...] \n " ,
2009-08-04 19:53:04 +04:00
force_ARG , noudevsync_ARG , test_ARG )
2001-09-25 16:49:28 +04:00
xx ( vgrename ,
" Rename a volume group " ,
2008-04-03 01:23:39 +04:00
0 ,
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 "
" \t [-t|--test] \n "
" \t [-v|--verbose] \n "
2002-12-12 23:55:49 +03: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 " ,
2001-11-28 21:03:11 +03:00
autobackup_ARG , force_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 " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2002-12-12 23:55:49 +03:00
" vgs " " \n "
" \t [--aligned] \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 "
2002-12-12 23:55:49 +03:00
" \t [-d|--debug] \n "
" \t [-h|--help] \n "
" \t [--ignorelockingfailure] \n "
2013-10-02 00:20:10 +04:00
" \t [--ignoreskippedcluster] \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 "
" \t [-o|--options [+]Field[,Field]] \n "
" \t [-O|--sort [+|-]key1[,[+|-]key2[,...]]] \n "
" \t [-P|--partial] " " \n "
2014-04-18 05:46:34 +04:00
" \t [--readonly] \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
2013-10-02 00:20:10 +04:00
aligned_ARG , all_ARG , ignorelockingfailure_ARG , ignoreskippedcluster_ARG ,
2014-05-29 11:38:59 +04:00
nameprefixes_ARG , noheadings_ARG , nolocking_ARG , nosuffix_ARG , options_ARG ,
partial_ARG , readonly_ARG , rows_ARG , select_ARG , separator_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 " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
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 "
2002-11-29 18:02:57 +03:00
" \t [-P|--partial] " " \n "
2006-05-12 23:16:48 +04:00
" \t [-v|--verbose] \n "
2002-12-12 23:55:49 +03:00
" \t [--version] " " \n " ,
2002-11-28 18:27:29 +03:00
2012-03-27 15:04:46 +04:00
cache_ARG , ignorelockingfailure_ARG , mknodes_ARG , partial_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 ,
2001-12-03 23:23:53 +03:00
" vgsplit " " \n "
" \t [-A|--autobackup {y|n}] " " \n "
2008-01-15 00:07:58 +03:00
" \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 "
2001-12-03 23:23:53 +03:00
" \t [-d|--debug] " " \n "
" \t [-h|--help] " " \n "
2008-01-15 00:07:58 +03:00
" \t [-l|--maxlogicalvolumes MaxLogicalVolumes] " " \n "
2002-11-18 17:04:08 +03:00
" \t [-M|--metadatatype 1|2] " " \n "
2010-06-29 00:39:24 +04:00
" \t [--[vg]metadatacopies #copies] " " \n "
2008-04-09 17:47:13 +04:00
" \t [-n|--name LogicalVolumeName] \n "
2008-01-15 00:07:58 +03:00
" \t [-p|--maxphysicalvolumes MaxPhysicalVolumes] " " \n "
2001-12-03 23:23:53 +03:00
" \t [-t|--test] " " \n "
" \t [-v|--verbose] " " \n "
" \t [--version] " " \n "
2008-01-15 00:07:58 +03:00
" \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 " ,
2010-10-25 15:20:54 +04:00
PERMITTED_READ_ONLY ,
2002-01-17 19:39:24 +03:00
" version \n " )
