1
0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-29 15:22:30 +03:00
Commit Graph

341 Commits

Author SHA1 Message Date
Zdenek Kabelac
11ea72cfd8 mirror: extra parsing for mirrorlog arg
Put validation of mirrorlog arg into a separate function.
2014-10-24 16:39:32 +02:00
David Teigland
17ab39f743 cache: include cache mode in vg metadata and display
The cache mode of a new cache pool is always explicitly
included in the vg metadata.  If a cache mode is not
specified on the command line, the cache mode is taken
from lvm.conf allocation/cache_pool_cachemode, which
defaults to "writethrough".

The cache mode can be displayed with lvs -o+cachemode.
2014-10-02 11:17:41 -05:00
Peter Rajnoha
f0cafc9281 conf: add allocation/physical_extent_size config option for default PE size of VGs.
Removes a need to use "vgcreate -s <desired PE size>" all the
time time just to override hardcoded default which is 4096KiB.
2014-09-12 10:09:21 +02:00
Zdenek Kabelac
3b5afac9b4 cleanup: use unsigned 1bit elements
Avoid using signed 'int' type for 1 bit size.
2014-08-26 14:13:06 +02:00
Zdenek Kabelac
e5356eeba1 cleanup: never return uninitialized buffer
Coverity noticed this function may return untouched buffer,
however in this state can't really happen, but anyway
ensure on error path the buffer will have zero lenght string.
2014-08-26 14:13:06 +02:00
Zdenek Kabelac
894eda4707 thin and cache: unify pool common code
Fix get_pool_params to only read params.
Add poolmetadataspare option to get_pool_params.
Move all profile code into update_pool_params.
Move recalculate code into pool_manip.c
2014-07-22 22:41:38 +02:00
Zdenek Kabelac
f9d80c9d31 cache: add tool support
Introducing cache tool support.
2014-07-11 12:47:35 +02:00
Peter Rajnoha
d169ff1e03 conf: add report/list_item_separator lvm.conf option
For example:

$ lvm dumpconfig report/list_item_separator
list_item_separator=","

$ lvs -o name,tags vg/lvol1
  LV    LV Tags
  lvol1 a,x,y

$ lvm dumpconfig report/list_item_separator
list_item_separator=":"

$ lvs -o name,tags vg/lvol1
  LV    LV Tags
  lvol1 ay
2014-07-10 16:18:45 +02:00
Jonathan Brassow
be75076dfc activation: Add "degraded" activation mode
Currently, we have two modes of activation, an unnamed nominal mode
(which I will refer to as "complete") and "partial" mode.  The
"complete" mode requires that a volume group be 'complete' - that
is, no missing PVs.  If there are any missing PVs, no affected LVs
are allowed to activate - even RAID LVs which might be able to
tolerate a failure.  The "partial" mode allows anything to be
activated (or at least attempted).  If a non-redundant LV is
missing a portion of its addressable space due to a device failure,
it will be replaced with an error target.  RAID LVs will either
activate or fail to activate depending on how badly their
redundancy is compromised.

This patch adds a third option, "degraded" mode.  This mode can
be selected via the '--activationmode {complete|degraded|partial}'
option to lvchange/vgchange.  It can also be set in lvm.conf.
The "degraded" activation mode allows RAID LVs with a sufficient
level of redundancy to activate (e.g. a RAID5 LV with one device
failure, a RAID6 with two device failures, or RAID1 with n-1
failures).  RAID LVs with too many device failures are not allowed
to activate - nor are any non-redundant LVs that may have been
affected.  This patch also makes the "degraded" mode the default
activation mode.

The degraded activation mode does not yet work in a cluster.  A
new cluster lock flag (LCK_DEGRADED_MODE) will need to be created
to make that work.  Currently, there is limited space for this
extra flag and I am looking for possible solutions.  One possible
solution is to usurp LCK_CONVERT, as it is not used.  When the
locking_type is 3, the degraded mode flag simply gets dropped and
the old ("complete") behavior is exhibited.
2014-07-09 22:56:11 -05:00
Peter Rajnoha
da545ce3b4 tools: add --binary arg to pvs,vgs,lvs and {pv,vg,lv}display -C and report/binary_values_as_numeric lvm.conf option
The --binary option, if used, causes all the binary values reported
in reporting commands to be displayed as "0" or "1" instead of descriptive
literal values (value "unknown" is still used for values that could not be
determined).

Also, add report/binary_values_as_numeric lvm.conf option with the same
functionality as the --binary option (the --binary option prevails
if both --binary cmd option and report/binary_values_as_numeric lvm.conf
option is used at the same time). The report/binary_values_as_numeric is
also profilable.

This makes it easier to use and check lvm reporting command output in scripts.
2014-07-04 15:40:17 +02:00
Zdenek Kabelac
86e116450e cleanup: drop unneeded initialization
Code assigns this variable right after clearing.
2014-07-04 12:31:17 +02:00
Peter Rajnoha
3208396ce5 coverity: fix issues reported by coverity 2014-06-24 14:58:53 +02:00
Peter Rajnoha
9c937e7d54 dumpconfig: add --type profilable-command/profilable-metadata, --metadataprofile/--commandprofile
The dumpconfig now understands --commandprofile/--profile/--metadataprofile

The --commandprofile and --profile functionality is almost the same
with only one difference and that is that the --profile is just used
for dumping the content, it's not applied for the command itself
(while the --commandprofile profile is applied like it is done for
any other LVM command).

We also allow --metadataprofile for dumpconfig - dumpconfig *does not*
touch VG/LV and metadata in any way so it's OK to use it here (just for
dumping the content, checking the profile validity etc.).

The validity of the profile can be checked with:
      dumpconfig --commandprofile/--profile/--metadataprofile --validate

...depending on the profile type.

Also, mention --config in the dumpconfig help string so users know
that  dumpconfig handles this too (it did even before, but it was not
documented in the help string).
2014-05-20 16:27:07 +02:00
Peter Rajnoha
9e3e4d6994 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:21:48 +02:00
Peter Rajnoha
c5fbd2c59f config: add CFG_PROFILABLE_METADATA flag
Mark profilable settings with a separate CFG_PROFILABLE_METADATA
flag where the profile can be attached to VG/LV. This makes it possible
to differentiate global command-profilable settings (CFG_PROFILABLE flag)
and contextual metadata-profilable (per VG/LV) settings (CFG_PROFILABLE_METADATA flag).
2014-05-19 16:31:15 +02:00
Peter Rajnoha
9a324df3b3 config: fix incorrect profile initialization on cmd context refresh
When cmd refresh is called, we need to move any already loaded profiles
to profiles_to_load list which will cause their reload on subsequent
use. In addition to that, we need to take into account any change
in config/profile configuration setting on cmd context refresh
since this setting could be overriden with --config.

Also, when running commands in the shell, we need to remove the
global profile used from the configuration cascade so the profile
is not incorrectly reused next time when the --profile option is
not specified anymore for the next command in the shell.

This bug only affected profile specified by --profile cmd line
arg, not profiles referenced from LVM metadata.
2014-05-19 15:39:55 +02:00
Peter Rajnoha
c42f72867a config: attach cft_check_handle to each config tree instead of global cmd_context
Before, the cft_check_handle used to direct configuration checking
was part of cmd_context. It's better to attach this as part of the
exact config tree against which the check is done. This patch moves
the cft_check_handle out of cmd_context and it attaches it to the
config tree directly as dm_config_tree->custom->config_source->check_handle.

This change makes it easier to track the config tree check results
and provides less space for bugs as the results are directly attached
to the tree and we don't need to be cautious whether the global value
is correct or not (and whether it needs reinitialization) as it was
in the case when the cft_check_handle was part of cmd_context.
2014-05-19 15:38:04 +02:00
Peter Rajnoha
ff9d27a1c7 config: add CONFIG_FILE_SPECIAL config source id
Add CONFIG_FILE_SPECIAL config source id to make a difference between
real configuration tree (like lvm.conf and tag configs) and special purpose
configuration tree (like LVM metadata, persistent filter).

This makes it easier to attach correct customized data to the config
tree that is created out of the source then.
2014-05-19 15:37:41 +02:00
Alasdair G Kergon
5684cfcb1c report: Add metadata_percent to lvs_cols. 2014-05-15 08:32:27 +01:00
Zdenek Kabelac
85cf5a23d2 cleanup: improve error message
Update impossile to happen error message.
2014-05-13 10:33:17 +02:00
Zdenek Kabelac
a8042f33d0 coverity: check for profile
Ensure str is not NULL for analyzer.
2014-05-07 14:15:52 +02:00
Peter Rajnoha
8e8a47143f config: use devices/ignore_suspended_devices=0 by default
ignore_suspended_devices=0 is already used in lvm.conf we distribute,
but it was still "1" in the code (so it was used when lvm.conf value
was not defined). It should be "0" too.
2014-04-24 12:12:39 +02:00
Zdenek Kabelac
559c003ee2 cleanup: reduce inclusion of unnecessary headers
Remove those file which are not needed by .c files
or already include because the headers already needs them.
2014-04-18 16:38:50 +02:00
Alasdair G Kergon
cc72f340d7 thin: Support thin_check --clear-needs-check-flag.
Update thin provisioning tools to version 0.3.2 or later!
2014-04-04 02:22:40 +01:00
Peter Rajnoha
68bb639a08 config: fix compile error in config-settings.h if using --disable-dmeventd
config/config_settings.h:257:102: error: 'DMEVENTD_PATH' undeclared here (not in a function)
2014-03-31 15:57:42 +02:00
Peter Rajnoha
9446978e64 config: define default value for global/thin_disabled_features as NULL instead
Before:
  thin_disabled_features = ""
Now:
  thin_disabled_features = []

Which is a more correct and consistent way of specifying void array
though parses can handle both forms.
2014-03-24 16:31:27 +01:00
Peter Rajnoha
4e47c34ffc config: also check empty arrays for difference against default values 2014-03-24 16:30:47 +01:00
Peter Rajnoha
5dcec1734e dumpconfig: add dumpconfig --type diff to show differences from defaults 2014-03-24 15:35:54 +01:00
Peter Rajnoha
76ff38fa5c config: add support for comparing used config values with default ones 2014-03-24 15:35:47 +01:00
Peter Rajnoha
630e0af14e cleanup: move _get_def_array_values fn
So we can use reuse it for the code that will follow...
2014-03-24 15:20:19 +01:00
Peter Rajnoha
000e81a999 cleanup: add cmd_context reference to struct cft_check_handle
So we have all things needed to do a configuration check packaged
in one handle. It makes function calls inside a bit more readable.
2014-03-19 08:45:05 +01:00
Peter Rajnoha
21b3c983fd config: make global/lvdisplay_shows_full_device_path profilable 2014-03-18 09:49:53 +01:00
Peter Rajnoha
927784cd06 config: make global/suffix profilable and add it to lvm.conf
The global/suffix was missing from example lvm.conf but it can
be very useful when using lvm in scripts and now in profiles as well
Let's expose it more.
2014-03-18 09:24:17 +01:00
Peter Rajnoha
c1ce2cc86c config: make global/units and global/si_unit_consistency profilable 2014-03-17 16:07:29 +01:00
Peter Rajnoha
455f23586f config: make report settings profilable
Users can create several profiles for how the tools report
the output very easily and then just use

  <lvm reporting command> --profile <report_profile_name>
2014-03-17 14:27:49 +01:00
Peter Rajnoha
bf42119b22 config: accept empty values for global/thin_disabled_features
Let's do this the other way round - this makes more logic than commit b995f06.
So let's allow empty values for global/thin_disabled_features where
such an empty value now means "none of this features are disabled".
2014-03-12 15:53:20 +01:00
Peter Rajnoha
b995f06abf config: mark global/thin_disabled_features as having no default value
The global/thin_disabled_features should be marked as having no default
value. Otherwise the output from 'lvm dumpconfig --type default' would
have 'thin_disabled_features=""' which will produce an error message
'Ignoring empty string in config file ...' if such output is feed
back to lvm.
2014-03-12 15:17:52 +01:00
Peter Rajnoha
bfffccca94 config: keep config paths with variable names properly marked on output 2014-03-07 18:04:02 +01:00
Peter Rajnoha
eeff7729d9 config: use small local static buffer instead of mempool for temporary config path
We can't use mempool for temporary variable for configuration path inside
find_config_tree_* functions since these functions can use the mempool
themselves deeper in the code and we can free mempool chunks only from
top to bottom which is not the case here (some default string
configuration values can be allocated from the mempool).
2014-03-07 17:50:01 +01:00
Peter Rajnoha
7409009a20 cleanup: remove superfluous slash in default cache dir path 2014-03-07 13:03:09 +01:00
Peter Rajnoha
9a1d31a3c6 cleanup: remove superfluous forward declaration 2014-03-06 12:43:21 +01:00
Peter Rajnoha
74a3fc4e85 config: add default for allocation/cache_pool_chunk_size
The same as for allocation/thin_pool_chunk_size - the default value
used is just a starting point. The calculation continues using the
properties of the devices actually used.
2014-03-06 11:34:02 +01:00
Peter Rajnoha
d27868e94f config: runtime default for allocation/thin_pool_chunk_size
The allocation/thin_pool_chunk_size is a bit more complex. It's default
value is evaluated in runtime based on selected thin_pool_chunk_size_policy.
But the value is just a starting point. The calculation then continues
with dependency on the properties of the devices used. Which means for
such a default value, we know only the starting value.
2014-03-06 11:26:02 +01:00
Peter Rajnoha
932e75e89f config: separate cfg_def_default_value_hint out of cfg_def_get_default_value
If the config setting is defined as having no default value, but it's
still not NULL, it means such a value acts as a *hint* only
(e.g. a starting value from which the default value is calculated).

The new "cfg_def_get_default_value_hint" will always return the value
as defined in config_settings.h.

The original "cfg_def_get_default_value" will always return 0/NULL if
the config setting is defined with CFG_DEFAULT_UNDEFINED flag (hence
ignoring the hint).

This is needed for proper distiction between a correct default value
and the value which is just a hint or a starting point in calculation,
but it's not the final value (yes, we do have such settings!).
2014-03-06 11:18:19 +01:00
Peter Rajnoha
eecf191d3e config: runtime default for activation/mirror_image_fault_policy
The activation/mirror_image_fault_policy default value copies the
value (or default one) used for activation/mirror_device_fault_policy.
2014-03-06 11:16:23 +01:00
Peter Rajnoha
11039589d3 config: runtime default for config/profile_dir
The config/profile_dir default value takes LVM_SYSTEM_DIR into consideraton.
2014-03-06 11:16:04 +01:00
Peter Rajnoha
0da1e5d9f8 config: runtime default for backup/backup_dir, backup/archive_dir
The backup/backup_dir and backup/archive_dir default value is evaluated
in runtime and takes LVM_SYSTEM_DIR into consideration...
2014-03-06 11:15:21 +01:00
Peter Rajnoha
f6adef9825 config: runtime default for devices/cache, devices/cache_dir
The devices/cache and devices/cache_dir are evaluated in runtime this way:

  - if devices/cache is set, use it

  - if devices_cache/dir or devices/cache_file_prefix is set, make up a
    path out of that for devices/cache in runtime, taking into account
    the LVM_SYSTEM_DIR environment variable if set

  - otherwise make up the path out of default which is:
    <LVM_SYSTEM_DIR>/<cache_dir>/<cache_file_prefix>.cache

With the runtime defaults, we can encode this easily now. Also, the lvm
dumpconfig can show proper and exact information about this setting then
(the variant that shows default values).
2014-03-06 11:07:54 +01:00
Peter Rajnoha
b53ec37286 config: add CFG_DEFAULT_RUN_TIME for config options with runtime defaults
Previously, we declared a default value as undefined ("NULL") for
settings which require runtime context to be set first (e.g. settings
for paths that rely on SYSTEM_DIR environment variable or they depend
on any other setting in some way).

If we want to output default values as they are really used in runtime,
we should make it possible to define a default value as function which
is evaluated, not just providing a firm constant value as it was before.

This patch defines simple prototypes for such functions. Also, there's
new helper macros "cfg_runtime" and "cfg_array_runtime" - they provide
exactly the same functionality as the original "cfg" and "cfg_array"
macros when defining the configuration settings in config_settings.h,
but they don't set the constant default value. Instead, they automatically
link the configuration setting definition with one of these functions:

  typedef int (*t_fn_CFG_TYPE_BOOL) (struct cmd_context *cmd, struct profile *profile);
  typedef int (*t_fn_CFG_TYPE_INT) (struct cmd_context *cmd, struct profile *profile);
  typedef float (*t_fn_CFG_TYPE_FLOAT) (struct cmd_context *cmd, struct profile *profile);
  typedef const char* (*t_fn_CFG_TYPE_STRING) (struct cmd_context *cmd, struct profile *profile);
  typedef const char* (*t_fn_CFG_TYPE_ARRAY) (struct cmd_context *cmd, struct profile *profile);

(The new macros actually set the CFG_DEFAULT_RUNTIME flag properly and
set the default value link to the function accordingly).

Then such configuration setting requires a function of selected type to
be defined. This function has a predefined name:

  get_default_<id>

...where the <id> is the id of the setting as defined in
config_settings.h. For example "backup_archive_dir_CFG" if defined
as a setting with default value evaluated in runtime with "cfg_runtime"
will automatically have "get_default_backup_archive_dir_CFG" function
linked to this setting to get the default value.
2014-03-06 10:54:17 +01:00
Peter Rajnoha
e2870c94cf config: use mempool for config paths used in find_config_tree_* functions
Using mempool is much safer than using the global static variable.
The global variable would be rewritten on each find_config_tree_* call
and we need to be very careful not to get into this problem (we don't
do now, but we can with the patches for "runtime defaults" that will follow).
2014-03-06 10:50:47 +01:00