1
0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Commit Graph

143 Commits

Author SHA1 Message Date
Peter Rajnoha
a4724350e4 lvmconfig: add --withspaces option
We shouldn't be adding spaces by default in output as that
may be be used already in scripts and especially for the eval
in shell scripts where spaces are not allowed between key
and value!

Add --withspaces option to lvmconfig for pretty output with
more space in for readability.
2015-06-24 13:19:23 +02:00
David Teigland
1f318dbcee Ignore hyphens in long option names
The hyphens are removed from long option names before
being read.  This means that:

- Option name specifications in args.h must not include hyphens.
  (The hyphen in 'use-policies' is removed.)

- A user can include hyphens anywhere in the option name.
  All the following are equivalent:
  --vgmetadatacopies,
  --vg-metadata-copies,
  --v-g-m-e-t-a-d-a-t-a-c-o-p-i-e-s-
2015-06-16 09:35:52 -05:00
Ondrej Kozina
e587b0677b lvmpolld: Add standalone polldaemon.
See doc/lvmpolld_overview.txt
2015-05-09 00:59:18 +01:00
Peter Rajnoha
fc65269d68 lvmconfig: add supporting code for handling deprecated settings
This patch adds supporting code for handling deprecated settings.

Deprecated settings are not displayed by default in lvmconfig output
(except for --type current and --type diff). There's a new
"--showdeprecated" lvmconfig option to display them if needed.

Also, when using lvmconfig --withcomments, the comments with info
about deprecation are displayed for deprecated settings and with
lvmconfig --withversions, the version in which the setting was
deprecated is displayed in addition to the version of introduction.

If using --atversion with a version that is lower than the one
in which the setting was deprecated, the setting is then considered
as not deprecated (simply because at that version it was not
deprecated).

For example:

$ lvmconfig --type default activation
activation {
        ...
	raid_region_size=512
        ...
}

$ lvmconfig --type default activation --showdeprecated
activation {
        ...
	mirror_region_size=512
	raid_region_size=512
        ...
}

$ lvmconfig --type default activation --showdeprecated --withversions
activation {
        ...
	# Available since version 1.0.0.
	# Deprecated since version 2.2.99.
	mirror_region_size=512
	# Available since version 2.2.99.
	raid_region_size=512
        ...
}

$ lvmconfig --type default activation --showdeprecated --withcomments
activation {
        ...
	# Configuration option activation/mirror_region_size.
	# This has been replaced by the activation/raid_region_size
	# setting.
	# Size (in KB) of each copy operation when mirroring.
	# This configuration option is deprecated.
	mirror_region_size=512

	# Configuration option activation/raid_region_size.
	# Size in KiB of each raid or mirror synchronization region.
	# For raid or mirror segment types, this is the amount of
	# data that is copied at once when initializing, or moved
	# at once by pvmove.
	raid_region_size=512
        ...
}

$ lvmconfig --type default activation --withcomments --atversion 2.2.98
activation {
       ...
       # Configuration option activation/mirror_region_size.
       # Size (in KB) of each copy operation when mirroring.
       mirror_region_size=512
       ...
}
2015-04-30 17:55:04 +02:00
Peter Rajnoha
8b6b90b073 config: consolidate CFG_UNSUPPORTED and CFG_ADVANCED settings
These settings are in the "unsupported" group:

devices/loopfiles
log/activate_file
metadata/disk_areas (section)
metadata/disk_areas/<disk_area> (section)
metadata/disk_areas/<disk_area>/size
metadata/disk_areas/<disk_area>/id

These settings are in the "advanced" group:

devices/dir
devices/scan
devices/types
global/proc
activation/missing_stripe_filler
activation/mlock_filter
metadata/pvmetadatacopies
metadata/pvmetadataignore
metadata/stripesize
metadata/dirs

Also, this patch causes the --ignoreunsupported and --ignoreadvanced
switches to be honoured for all config types (lvmconfig --type).

By default, the --type current and --type diff display unsupported
settings, the other types ignore them - this patch also introduces
--showunsupported switch for all these other types to display even
unsupported settings in their output if needed.
2015-04-29 16:31:47 +02:00
Peter Rajnoha
0ba332e82a refactor: dumpconfig: keep --withcomments to display full comment and use --withsummary for one line summary 2015-04-29 11:14:18 +02:00
David Teigland
9b86e8e8f4 dumpconfig: add --ignorelocal
When generating a sample lvm.conf file, we don't want to
include the "local" section, which is kept in lvmlocal.conf.
2015-04-21 14:55:03 -05:00
David Teigland
5cd6381717 dumpconfig: add --unconfigured option
Using this option, default string values that are
configurable are printed as unconfigured values,
e.g. "@CONFDIR@" instead of "/etc".
2015-04-17 11:35:34 -05:00
David Teigland
5f6ac1c812 dumpconfig: add --withfullcomments option
--withfullcomments prints all comment lines for each config option.
--withcomments prints only the first comment line, which should be
a short one-line summary of the option.
2015-04-15 10:56:42 -05:00
David Teigland
8cdec4c434 system_id: use for VG ownership
See included lvmsystemid(7) for full description.
2015-02-13 10:10:27 -06:00
Zdenek Kabelac
2908ab3eed thin: errrorwhenfull support
Support error_if_no_space feature for thin pools.
Report more info about thinpool status:
(out_of_data (D), metadata_read_only (M), failed  (F) also as health
attribute.)
2015-01-14 14:52:05 +01:00
Petr Rockai
4b9b8e1282 toollib: Split --cachesettings from --cachepolicy. 2014-11-20 16:51:07 +01:00
Petr Rockai
f67e1fadb0 toollib: Add --cachepolicy and implement get_cachepolicy_params. 2014-11-20 16:51:06 +01:00
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
Zdenek Kabelac
a330640063 options: introduce pooldatasize option
Introduce new option to specify pool data size.
This will be user to create i.e.  cache & cachepool at once.
And possible for thin external origin snapshot.

This is only very basic patch to enable options, the
real working code will come later.
2014-10-24 16:39:32 +02:00
Zdenek Kabelac
9e85dbbfd0 cleanup: sort args alphabetically
Give it some order for easier human lookup for options we do support.
2014-10-24 16:39:31 +02:00
Zdenek Kabelac
a8497e329b lvconvert: options splitcache, split, uncache
--splitcache
  Splits only cached LV (also pool could be specified).
  Detaches cachepool from cached LV.

  --split
  Should be univerzal command to split various complex targets.
  At this moment it knows cache.

  --uncache
  Opposite command to --cache. Detaches and DELETES cachepool for
  cached LV.

Note: we support thin pool cached metadata device for uncaching.
Also use may specify wither cached LV or association cachepool device
to request split of cache.
2014-10-06 15:18:05 +02:00
Zdenek Kabelac
fc77e4291b commands: support shortcut -H for cache objects
Introduce cache_long_ARG for those instancies
where --cache is not related to caching LV.
(pvchange,vg|lv|pvscan).

cache_ARG is now with -H shortcut.
2014-10-06 15:18:05 +02:00
Zdenek Kabelac
de1ee0bc52 cleanup: move merge option
Put long --merge option into section with long options.
2014-07-11 13:32:21 +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
Alasdair G Kergon
b33091cb11 pvmove: tidy 2014-06-19 13:40:47 +01:00
Jonathan Brassow
5ebff6cc9f pvmove: Enable all-or-nothing (atomic) pvmoves
pvmove can be used to move single LVs by name or multiple LVs that
lie within the specified PV range (e.g. /dev/sdb1:0-1000).  When
moving more than one LV, the portions of those LVs that are in the
range to be moved are added to a new temporary pvmove LV.  The LVs
then point to the range in the pvmove LV, rather than the PV
range.

Example 1:
	We have two LVs in this example.  After they were
	created, the first LV was grown, yeilding two segments
	in LV1.  So, there are two LVs with a total of three
	segments.

	Before pvmove:
	      ---------  ---------   ---------
	      | LV1s0 |  | LV2s0 |   | LV1s1 |
	      ---------  ---------   ---------
	         |           |           |
	   -------------------------------------
	PV | 000 - 255 | 256 - 511 | 512 - 767 |
	   -------------------------------------

	After pvmove inserts the temporary pvmove LV:
	          ---------   ---------   ---------
	          | LV1s0 |   | LV2s0 |   | LV1s1 |
	          ---------   ---------   ---------
	              |           |           |
	        -------------------------------------
	pvmove0 |   seg 0   |   seg 1   |   seg 2   |
	        -------------------------------------
	              |           |           |
	        -------------------------------------
	PV      | 000 - 255 | 256 - 511 | 512 - 767 |
	        -------------------------------------

	Each of the affected LV segments now point to a
	range of blocks in the pvmove LV, which purposefully
	corresponds to the segments moved from the original
	LVs into the temporary pvmove LV.

The current implementation goes on from here to mirror the temporary
pvmove LV by segment.  Further, as the pvmove LV is activated, only
one of its segments is actually mirrored (i.e. "moving") at a time.
The rest are either complete or not addressed yet.  If the pvmove
is aborted, those segments that are completed will remain on the
destination and those that are not yet addressed or in the process
of moving will stay on the source PV.  Thus, it is possible to have
a partially completed move - some LVs (or certain segments of LVs)
on the source PV and some on the destination.

Example 2:
	What 'example 1' might look if it was half-way
	through the move.
	             ---------   ---------   ---------
	             | LV1s0 |   | LV2s0 |   | LV1s1 |
	             ---------   ---------   ---------
	                 |           |           |
	           -------------------------------------
	pvmove0    |   seg 0   |   seg 1   |   seg 2   |
	           -------------------------------------
	                 |           |           |
	                 |     -------------------------
	source PV        |     | 256 - 511 | 512 - 767 |
	                 |     -------------------------
	                 |           ||
	           -------------------------
	dest PV    | 000 - 255 | 256 - 511 |
	           -------------------------

This update allows the user to specify that they would like the
pvmove mirror created "by LV" rather than "by segment".  That is,
the pvmove LV becomes an image in an encapsulating mirror along
with the allocated copy image.

Example 3:
	A pvmove that is performed "by LV" rather than "by segment".

	                   ---------   ---------
	                   | LV1s0 |   | LV2s0 |
	                   ---------   ---------
	                       |           |
	                 -------------------------
	        pvmove0  |  * LV-level mirror *  |
	                 -------------------------
                             /                \
	   pvmove_mimage0   /          pvmove_mimage1
	   -------------------------   -------------------------
	   |   seg 0   |   seg 1   |   |   seg 0   |   seg 1   |
	   -------------------------   -------------------------
	        |            |               |           |
	   -------------------------   -------------------------
	   | 000 - 255 | 256 - 511 |   | 000 - 255 | 256 - 511 |
	   -------------------------   -------------------------
	           source PV                    dest PV

The thing that differentiates a pvmove done in this way and a simple
"up-convert" from linear to mirror is the preservation of the
distinct segments.  A normal up-convert would simply allocate the
necessary space with no regard for segment boundaries.  The pvmove
operation must preserve the segments because they are the critical
boundary between the segments of the LVs being moved.  So, when the
pvmove copy image is allocated, all corresponding segments must be
allocated.  The code that merges ajoining segments that are part of
the same LV when the metadata is written must also be avoided in
this case.  This method of mirroring is unique enough to warrant its
own definitional macro, MIRROR_BY_SEGMENTED_LV.  This joins the two
existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV
(for user created mirrors).

The advantages of performing pvmove in this way is that all of the
LVs affected can be moved together.  It is an all-or-nothing approach
that leaves all LV segments on the source PV if the move is aborted.
Additionally, a mirror log can be used (in the future) to provide tracking
of progress; allowing the copy to continue where it left off in the event
there is a deactivation.
2014-06-17 22:59:36 -05:00
Peter Rajnoha
5b734a0ea1 report: select: add --select arg to pvs, vgs and lvs 2014-06-17 16:27:20 +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
Alasdair G Kergon
b5f8f452ac tools: Add --readonly support.
Offer lock-free access to display virtual machine or clustered VG metadata
while it might be in use.
2014-04-18 02:46:34 +01:00
Jonathan Brassow
0912cf67aa cache: Ability to convert an existing LV into a cached LV
Users now have the ability to convert their existing logical volumes
into cached logical volumes.  A cache pool LV must be specified using
the '--cachepool' argument.  The cachepool is the small, fast LV used
to cache the large, slow LV that is being converted.
2014-02-12 09:55:35 -06:00
Jonathan Brassow
97be8b3482 cache: Code changes to allow creation of cache pools
This patch allows the creation and removal of cache pools.  Users are not
yet able to create cache LVs.  They are only able to define the space used
for the cache and its characteristics (chunk_size and cache mode ATM) by
creating the cache pool.
2014-02-04 11:57:08 -06:00
Alasdair G Kergon
7b65363bf7 lvconvert: Implement --splitsnapshot. 2013-12-04 02:09:37 +00:00
Peter Rajnoha
169b4c1586 lvcreate: recognize --wipesignatures arg
Recognize the new --wipesignatures arg in lvcreate that is supposed
to wipe known signatures if found on newly created LV.
2013-11-27 15:48:15 +01:00
Alasdair G Kergon
baf95bbff7 cmdline: Add --ignoreskippedcluster.
Accept --ignoreskippedcluster with pvs, vgs, lvs, pvdisplay, vgdisplay,
lvdisplay, vgchange and lvchange to avoid the 'Skipping clustered
VG' errors when requesting information about a clustered VG
without using clustered locking and still exit with success.

The messages can still be seen with -v.
2013-10-01 21:20:10 +01:00
Alasdair G Kergon
5face2010d tools: Use backgroundfork_ARG for pvscan -b
Change pvscan -b to use a new backgroundfork_ARG instead of
background_ARG so as not to affect pvmove -b and lvconvert -b.
2013-09-06 01:43:24 +01:00
Alasdair G Kergon
90a09559ed commandline: add prefix aliases for raid options
Accept --raidwritemostly as well as --writemostly etc.
2013-07-19 19:24:54 +01:00
Zdenek Kabelac
460d0254eb thin: add pool metadata spare lv support
Add support for pool's metadata spare volume.
2013-07-18 18:22:43 +02:00
Peter Rajnoha
7dc8c84b18 activation: add support for skipping activation of selected LVs
Also add -k/--setactivationskip y/n and -K/--ignoreactivationskip
options to lvcreate.

The --setactivationskip y sets the flag in metadata for an LV to
skip the LV during activation. Also, the newly created LV is not
activated.

Thin snapsots have this flag set automatically if not specified
directly by the --setactivationskip y/n option.

The --ignoreactivationskip overrides the activation skip flag set
in metadata for an LV (just for the run of the command - the flag
is not changed in metadata!)

A few examples for the lvcreate with the new options:

  (non-thin snap LV => skip flag not set in MDA + LV activated)
  raw/~ $ lvcreate -l1 vg
    Logical volume "lvol0" created
  raw/~ $ lvs -o lv_name,attr vg/lvol0
    LV    Attr
    lvol0 -wi-a----

  (non-thin snap LV + -ky => skip flag set in MDA + LV not activated)
  raw/~ $ lvcreate -l1 -ky vg
    Logical volume "lvol1" created
  raw/~ $ lvs -o lv_name,attr vg/lvol1
    LV    Attr
    lvol1 -wi------

  (non-thin snap LV + -ky + -K => skip flag set in MDA + LV activated)
  raw/~ $ lvcreate -l1 -ky -K vg
    Logical volume "lvol2" created
  raw/~ $ lvs -o lv_name,attr vg/lvol2
    LV    Attr
    lvol2 -wi-a----

  (thin snap LV => skip flag set in MDA (default behaviour) + LV not activated)
  raw/~ $ lvcreate -L100M -T vg/pool -V 1T -n thin_lv
    Logical volume "thin_lv" created
  raw/~ $ lvcreate -s vg/thin_lv -n thin_snap
    Logical volume "thin_snap" created
  raw/~ $ lvs -o name,attr vg
    LV        Attr
    pool      twi-a-tz-
    thin_lv   Vwi-a-tz-
    thin_snap Vwi---tz-

  (thin snap LV + -K => skip flag set in MDA (default behaviour) + LV activated)
  raw/~ $ lvcreate -s vg/thin_lv -n thin_snap -K
    Logical volume "thin_snap" created
  raw/~ $ lvs -o name,attr vg/thin_lv
    LV      Attr
    thin_lv Vwi-a-tz-

  (thins snap LV + -kn => no skip flag in MDA (default behaviour overridden) + LV activated)
  [0] raw/~ # lvcreate -s vg/thin_lv -n thin_snap -kn
    Logical volume "thin_snap" created
  [0] raw/~ # lvs -o name,attr vg/thin_snap
    LV        Attr
    thin_snap Vwi-a-tz-
2013-07-12 20:39:07 +02:00
Peter Rajnoha
5ed7d0cf1d dumpconfig: add --mergedconfig option
Normally, the lvm dumpconfig processes only the configuration tree
that is at the top of the cascade. Considering the cascade is:

  CONFIG_STRING -> CONFIG_PROFILE -> CONFIG_MERGED_FILES/CONFIG_FILE

...then:

  (dumpconfig of lvm.conf only)
  raw/~ $ lvm dumpconfig allocation
  allocation {
	  maximise_cling=1
	  mirror_logs_require_separate_pvs=0
	  thin_pool_metadata_require_separate_pvs=0
	  thin_pool_chunk_size=64
  }

  (dumpconfig of selected profile configuration only)
  raw/~ $ lvm dumpconfig --profile test allocation
  allocation {
	  thin_pool_chunk_size=8
	  thin_pool_discards="passdown"
	  thin_pool_zero=1
  }

  (dumpconfig of given --config configuration only)
  raw/~ $ lvm dumpconfig --config 'allocation{thin_pool_chunk_size=16}' allocation
  allocation {
	  thin_pool_chunk_size=16
  }

The --mergedconfig option causes the configuration cascade to be
merged before processing it with dumpconfig:

  (dumpconfig of merged selected profile and lvm.conf)
  raw/~ $ lvm dumpconfig --profile test allocation --mergedconfig
  allocation {
	  maximise_cling=1
	  thin_pool_zero=1
	  thin_pool_discards="passdown"
	  mirror_logs_require_separate_pvs=0
	  thin_pool_metadata_require_separate_pvs=0
	  thin_pool_chunk_size=8
  }

  (dumpconfig merged given --config and selected profile and lvm.conf)
  raw/~ $ lvm dumpconfig --profile test --config 'allocation{thin_pool_chunk_size=16}' allocation --mergedconfig
  allocation {
	  maximise_cling=1
	  thin_pool_zero=1
	  thin_pool_discards="passdown"
	  mirror_logs_require_separate_pvs=0
	  thin_pool_metadata_require_separate_pvs=0
	  thin_pool_chunk_size=16
  }

Hence with the --mergedconfig, we are able to see the
configuration that is actually used when processing any
LVM command while using any combination of --config/--profile
options together with lvm.conf file.
2013-07-08 16:05:56 +02:00
Peter Rajnoha
0cd4794735 tools: add support for changing configuration profile for existing volumes (vgchange/lvchange)
The command to change the profile for existing VG/LV:
	"vgchange/lvchange --profile <profile_name>"

The command to detach any existing profile from VG/LV:
	"vgchange/lvchange --detachprofile"
2013-07-02 15:22:10 +02:00
Peter Rajnoha
ebc236d085 config: add support for loading profiles
This patch adds --profile arg to lvm cmds and adds config/profile_dir
configuration setting to select the directory where profiles are stored
By default it's /etc/lvm/profile.

The profiles are added by using new "add_profile" fn and then loaded
using the "load_profile" fn. All profiles are stored in a cmd context
within the new "struct profile_params":

struct profile_params {
  const char *dir;
  struct profile *global_profile;
  struct dm_list profiles_to_load;
  struct dm_list profiles;
};

...where "dir" is the directory with profiles, "global_profile" is
the profile that is set globally via the --profile arg (IOW, not
set per VG/LV basis based on metadata record) and the "profiles"
is the list with loaded profiles.
2013-07-02 15:19:08 +02:00
Jonathan Brassow
562c678ee2 DM RAID: Add ability to throttle sync operations for RAID LVs.
This patch adds the ability to set the minimum and maximum I/O rate for
sync operations in RAID LVs.  The options are available for 'lvcreate' and
'lvchange' and are as follows:
  --minrecoveryrate <Rate> [bBsSkKmMgG]
  --maxrecoveryrate <Rate> [bBsSkKmMgG]
The rate is specified in size/sec/device.  If a suffix is not given,
kiB/sec/device is assumed.  Setting the rate to 0 removes the preference.
2013-05-31 11:25:52 -05:00
Peter Rajnoha
732859d21f refactor: rename embedding area -> bootloader area 2013-05-28 12:37:22 +02:00
Jonathan Brassow
2e0740f7ef RAID: Add writemostly/writebehind support for RAID1
'lvchange' is used to alter a RAID 1 logical volume's write-mostly and
write-behind characteristics.  The '--writemostly' parameter takes a
PV as an argument with an optional trailing character to specify whether
to set ('y'), unset ('n'), or toggle ('t') the value.  If no trailing
character is given, it will set the flag.
Synopsis:
        lvchange [--writemostly <PV>:{t|y|n}] [--writebehind <count>] vg/lv
Example:
        lvchange --writemostly /dev/sdb1:y --writebehind 512 vg/raid1_lv

The last character in the 'lv_attr' field is used to show whether a device
has the WriteMostly flag set.  It is signified with a 'w'.  If the device
has failed, the 'p'artial flag has priority.

Example ("nosync" raid1 with mismatch_cnt and writemostly):
[~]# lvs -a --segment vg
  LV                VG   Attr      #Str Type   SSize
  raid1             vg   Rwi---r-m    2 raid1  500.00m
  [raid1_rimage_0]  vg   Iwi---r--    1 linear 500.00m
  [raid1_rimage_1]  vg   Iwi---r-w    1 linear 500.00m
  [raid1_rmeta_0]   vg   ewi---r--    1 linear   4.00m
  [raid1_rmeta_1]   vg   ewi---r--    1 linear   4.00m

Example (raid1 with mismatch_cnt, writemostly - but failed drive):
[~]# lvs -a --segment vg
  LV                VG   Attr      #Str Type   SSize
  raid1             vg   rwi---r-p    2 raid1  500.00m
  [raid1_rimage_0]  vg   Iwi---r--    1 linear 500.00m
  [raid1_rimage_1]  vg   Iwi---r-p    1 linear 500.00m
  [raid1_rmeta_0]   vg   ewi---r--    1 linear   4.00m
  [raid1_rmeta_1]   vg   ewi---r-p    1 linear   4.00m

A new reportable field has been added for writebehind as well.  If
write-behind has not been set or the LV is not RAID1, the field will
be blank.
Example (writebehind is set):
[~]# lvs -a -o name,attr,writebehind vg
  LV            Attr      WBehind
  lv            rwi-a-r--     512
  [lv_rimage_0] iwi-aor-w
  [lv_rimage_1] iwi-aor--
  [lv_rmeta_0]  ewi-aor--
  [lv_rmeta_1]  ewi-aor--

Example (writebehind is not set):
[~]# lvs -a -o name,attr,writebehind vg
  LV            Attr      WBehind
  lv            rwi-a-r--
  [lv_rimage_0] iwi-aor-w
  [lv_rimage_1] iwi-aor--
  [lv_rmeta_0]  ewi-aor--
  [lv_rmeta_1]  ewi-aor--
2013-04-15 13:59:46 -05:00
Jonathan Brassow
ff64e3500f RAID: Add scrubbing support for RAID LVs
New options to 'lvchange' allow users to scrub their RAID LVs.
Synopsis:
	lvchange --syncaction {check|repair} vg/raid_lv

RAID scrubbing is the process of reading all the data and parity blocks in
an array and checking to see whether they are coherent.  'lvchange' can
now initaite the two scrubbing operations: "check" and "repair".  "check"
will go over the array and recored the number of discrepancies but not
repair them.  "repair" will correct the discrepancies as it finds them.

'lvchange --syncaction repair vg/raid_lv' is not to be confused with
'lvconvert --repair vg/raid_lv'.  The former initiates a background
synchronization operation on the array, while the latter is designed to
repair/replace failed devices in a mirror or RAID logical volume.

Additional reporting has been added for 'lvs' to support the new
operations.  Two new printable fields (which are not printed by
default) have been added: "syncaction" and "mismatches".  These
can be accessed using the '-o' option to 'lvs', like:
	lvs -o +syncaction,mismatches vg/lv
"syncaction" will print the current synchronization operation that the
RAID volume is performing.  It can be one of the following:
        - idle:   All sync operations complete (doing nothing)
        - resync: Initializing an array or recovering after a machine failure
        - recover: Replacing a device in the array
        - check: Looking for array inconsistencies
        - repair: Looking for and repairing inconsistencies
The "mismatches" field with print the number of descrepancies found during
a check or repair operation.

The 'Cpy%Sync' field already available to 'lvs' will print the progress
of any of the above syncactions, including check and repair.

Finally, the lv_attr field has changed to accomadate the scrubbing operations
as well.  The role of the 'p'artial character in the lv_attr report field
as expanded.  "Partial" is really an indicator for the health of a
logical volume and it makes sense to extend this include other health
indicators as well, specifically:
        'm'ismatches:  Indicates that there are discrepancies in a RAID
                       LV.  This character is shown after a scrubbing
                       operation has detected that portions of the RAID
                       are not coherent.
        'r'efresh   :  Indicates that a device in a RAID array has suffered
                       a failure and the kernel regards it as failed -
                       even though LVM can read the device label and
                       considers the device to be ok.  The LV should be
                       'r'efreshed to notify the kernel that the device is
                       now available, or the device should be 'r'eplaced
                       if it is suspected of failing.
2013-04-11 15:33:59 -05:00
Peter Rajnoha
7d6991e900 dumpconfig: add --ignoreadvanced and --ignoreunsupported switch
lvm dumpconfig [--ignoreadvanced] [--ignoreunsupported]

--ignoreadvanced causes the advanced configuration options to be left
out on dumpconfig output

--ignoreunsupported causes the options that are not officially supported
to be lef out on dumpconfig output
2013-03-06 10:46:36 +01:00
Peter Rajnoha
088d88cfe2 dumpconfig: add --withcomments and --withversions switch
lvm dumpconfig [--withcomments] [--withversions]

The --withcomments causes the comments to appear on output before each
config node (if they were defined in config_settings.h).

The --withversions causes a one line extra comment to appear on output
before each config node with the version information in which the
configuration setting first appeared.
2013-03-06 10:46:36 +01:00
Peter Rajnoha
34350963d1 dumpconfig: add --type, --atversion and --validate arg
lvm dumpconfig [--type {current|default|missing|new}] [--atversion] [--validate]

This patch adds above-mentioned args to lvm dumpconfig and it maps them
to creation and writing out a configuration tree of a specific type
(see also previous commit):

  - current maps to CFG_TYPE_CURRENT
  - default maps to CFG_TYPE_DEFAULT
  - missing maps to CFG_TYPE_MISSING
  - new maps to CFG_TYPE_NEW

If --type is not defined, dumpconfig defaults to "--type current"
which is the original behaviour of dumpconfig before all these changes.

The --validate option just validates current configuration tree
(lvm.conf/--config) and it writes a simple status message:

  "LVM configuration valid" or "LVM configuration invalid"
2013-03-06 10:46:36 +01:00
Peter Rajnoha
86f65a3f2b tools: add embeddingareasize arg to pvcreate and vgconvert
To create an Embedding Area during PV creation (pvcreate or as part of
the vgconvert operation), we need to define the Embedding Area size.
The Embedding Area start will be calculated automatically by the tools.

This patch adds --embeddingareasize argument to pvcreate and vgconvert.
2013-02-26 14:46:41 +01:00
Zdenek Kabelac
b73de73151 thin: lvconvert support for external origin
Add basic support for converting LV into an external origin volume.

Syntax:

lvconvert --thinpool vg/pool  --originname renamed_origin -T origin

It will convert volume  'origin' into a thin volume, which will
use 'renamed_origin' as an external read-only origin.
All read/write into origin will go via 'pool'.

renamed_origin volume is read-only volume, that could be activated
only in read-only mode, and cannot be modified.
2013-02-23 10:38:20 +01:00
Zdenek Kabelac
09b7ceea95 thin: allow restore with --force
Allow restoring metadata with thin pool volumes.
No validation is done for this case within vgcfgrestore tool -
thus incorrect metadata may lead to destruction of pool content.
2012-11-27 14:08:24 +01:00
Zdenek Kabelac
a27650cc98 thin: lvconvert
Update code for lvconvert.
Change the lvconvert user interface a bit - now we require 2 specifiers
--thinpool   takes LV name for data device (and makes the name)
--poolmetadata  takes LV name for metadata device.

Fix type in thin help text -z -> -Z.

Supported is also new flag --discards for thinpools.
2012-10-03 15:13:33 +02:00
Alasdair G Kergon
438e0050df config: add silent mode
Accept -q as the short form of --quiet.
Suppress non-essential standard output if -q is given twice.
Treat log/silent in lvm.conf as equivalent to -qq.
Review all log_print messages and change some to
log_print_unless_silent.

When silent, the following commands still produce output:
dumpconfig, lvdisplay, lvmdiskscan, lvs, pvck, pvdisplay,
pvs, version, vgcfgrestore -l, vgdisplay, vgs.
[Needs checking.]

Non-essential messages are shifted from log level 4 to log level 5
for syslog and lvm2_log_fn purposes.
2012-08-25 20:35:48 +01:00