vgcfgrestore: Remove the VG from lvmetad before overwriting it.

man: lvs man page was not accurate on the volume health bit of lv_attr

The 'm'ismatches flag only shows after a "check" scrubbing operation -
not after a "check" or "repair" as indicated by the man page.

dmsetup: Detect invalid sector supplied to message.

atoll doesn't check for errors, so invalid sector numbers were silently
accepted in the "dmsetup message" command.

(Mikulas)

tools: Avoid overflow in _get_int_arg.

Use strtoull instead of strtol so that argument size is not cut
to 31 bytes on machines with 32-bit long.

(Mikulas)

libdm: avoid leak if dm_task_set_* fn called again

(Mikulas)

reporting: Add devtypes command.

Add internal devtypes reporting command to display built-in recognised
block device types.  (The output does not include any additional
types added by a configuration file.)

> lvm devtypes -o help
  Device Types Fields
  -------------------
    devtype_all            - All fields in this section.
    devtype_name           - Name of Device Type exactly as it appears in /proc/devices.
    devtype_max_partitions - Maximum number of partitions. (How many device minor numbers get reserved for each device.)
    devtype_description    - Description of Device Type.

> lvm devtypes
  DevType       MaxParts Description
  aoe                 16 ATA over Ethernet
  ataraid             16 ATA Raid
  bcache               1 bcache block device cache
  blkext               1 Extended device partitions
...

WHATS_NEW: Better description for commit 82228ac

More correct description of changes made to disallow thin+mirror.

debug: Use // for commented out debug #defines

The traditional style used for optional editable definitions
/* #define X /* */
produces a bogus warning from gcc -Wall.

Rather than suppressing this with -Wno-comment, switch over to
the // comment style.

Makefiles: Fix CC variable override.

The CC override in commit f42b2d4bbf16345e5b5457f4298e751d5c134776
caused the built-in value to be used instead of the configured value
when it wasn't being overridden.

The behaviour is explained here:
http://stackoverflow.com/questions/18007326/how-to-change-default-values-of-variables-like-cc-in-makefile

filters: Add bcache.

N.B. Using bcache devices as PVs is still experimental.
Problems should be reported to the appropriate mailing lists.

doc: add a note about device filtering while lvmetad is used

tests: no activate LV

Since our current vgcfgbackup/restore doesn't deal
with difference of active volumes between current and
restored set of volumes -  run test with inactive LVs.

tests: update vgcfgrestore test

Test vgcfgrestore when seqno of restored mda is smaller then current
metadata on device.

systemd: run lvm2-activation-net.service after lvm2-activation.service

The lvm2-activation-net.service was ordered only with respect to iscsi
and fcoe service before. In addition to that, we also need ordering
with respect to lvm2-activation.service to prevent parallel vgchange -aay
runs which may cause some problems during activation.
See also https://bugs.gentoo.org/show_bug.cgi?id=480066.

With this patch, the ordering is firmly set to:
lvm2-activation-early.service -> lvm2-activation.service -> lvm2-activation-net.service

Thanks to Alexander Tsoy for the original patch (modified a bit here):
https://www.redhat.com/archives/lvm-devel/2013-September/msg00049.html

tests: enhance pvmove testing

Rewrite check lv_on  and add new  lv_tree_on
Move more pvmove test unrelated code out to check & get sections
(so they do not obfuscate trace output unnecesserily)

Use new lv_tree_on()
NOTE: unsure how the snapshot origin should be accounted here.

Split pmove-all-segments into separate tests for raid and thins
(so the test output properly shows what has been skipped in test)

tests: use check for raid test

Use test-suite built-in check command for this test
(creates better logs, and reduces amount of valgrind-ed commands)

tests: update check and get

Update usage of "" around shell vars.
trim needs to trim both sides now.
trim also removes debug.log since it's only called when lvm command
has finished properly (so if something fails afterward, there
is no missleading debug trace in the log)

tests: update die

'die' evaluates given string - so \n could be used for
multiline error report

Also remove debug.log since the command finished properly when we
call 'die'

Note: we should not call 'die' after lvm command failure.

tests: add help function

Add mkdev_md5sum to create and checksum given LV.
Add dev_md5sum to verify device has matching md5 sum.

TEST: Unaccounted possible output causing failure

lvchange-raid.sh checks to ensure that the 'p'artial flag takes
precedence over the 'w'ritemostly flag by disabling and reenabling
a device in the array.  Most of the time this works fine, but
sometimes the kernel can notice the device failure before it is
reenabled.  In that case, the attr flag will not return to 'w', but
to 'r'efresh.  This is because 'r'efresh also takes precedence over
the 'w'ritemostly flag.  So, we also do a quick check for 'r' and
not just 'w'.

WHATS_NEW: some missing lines

udev: keep DM_ACTIVATION and DM_UDEV_PRIMARY_SOURCE_FLAG meaning as before commit 8d1d835

The DM_ACTIVATION and DM_UDEV_PRIMARY_SOURCE_FLAG needs to be kept the
way it was for backward compatibility (e.g. the old rules are still
in initramfs). This way the check in whether the device should be
scanned in 69-dm-lvmetad.rules is even easier.

tests: extend harness with output of /var/log/messages

Add a very simple hack for embeding /var/log/messages into
the tests output - it's not ideal since it sometimes breaks lines,
but still gives valuable info.

tests: singlenode cleanup for prev commit

Add few more comments and cleanup some warnings.

tests: singlenode updates

Add more 'realistic' simulation of dlm locking.
Previous version was not capable to maintain multiple locks.
Current version doesn't handle multiqueues for locks,
so the ordering is different.

clvmd: add missing debug newline

Just missing new line.

cleanup: hide gcc warning

Older gcc is giving misleading warning:

metadata/lv_manip.c:4018: warning: ‘seg’ may be used uninitialized in
this function

But warning free compilation is better.

Mirror/Thin: Disallow thinpools on mirror logical volumes

The same corner cases that exist for snapshots on mirrors exist for
any logical volume layered on top of mirror.  (One example is when
a mirror image fails and a non-repair LVM command is the first to
detect it via label reading.  In this case, the LVM command will hang
and prevent the necessary LVM repair command from running.)  When
a better alternative exists, it makes no sense to allow a new target
to stack on mirrors as a new feature.  Since, RAID is now capable of
running EX in a cluster and thin is not active-active aware, it makes
sense to pair these two rather than mirror+thinpool.

As further background, here are some additional comments that I made
when addressing a bug related to mirror+thinpool:
(https://bugzilla.redhat.com/show_bug.cgi?id=919604#c9)
I am going to disallow thin* on top of mirror logical volumes.
Users will have to use the "raid1" segment type if they want this.

This bug has come down to a choice between:
1) Disallowing thin-LVs from being used as PVs.
2) Disallowing thinpools on top of mirrors.

The problem is that the code in dev_manager.c:device_is_usable() is unable
to tell whether there is a mirror device lower in the stack from the device
being checked.  Pretty much anything layered on top of a mirror will suffer
from this problem.  (Snapshots are a good example of this; and option #1
above has been chosen to deal with them.  This can also be seen in
dev_manager.c:device_is_usable().)  When a mirror failure occurs, the
kernel blocks all I/O to it.  If there is an LVM command that comes along
to do the repair (or a different operation that requires label reading), it
would normally avoid the mirror when it sees that it is blocked.  However,
if there is a snapshot or a thin-LV that is on a mirror, the above code
will not detect the mirror underneath and will issue label reading I/O.
This causes the command to hang.

Choosing #1 would mean that thin-LVs could never be used as PVs - even if
they are stacked on something other than mirrors.

Choosing #2 means that thinpools can never be placed on mirrors.  This is
probably better than we think, since it is preferred that people use the
"raid1" segment type in the first place.  However, RAID* cannot currently
be used in a cluster volume group - even in EX-only mode.  Thus, a complete
solution for option #2 must include the ability to activate RAID logical
volumes (and perform RAID operations) in a cluster volume group.  I've
already begun working on this.

WHATS_NEW: one more for commit 8d1d835

WHATS_NEW: for commit 8d1d8350 and 72a9d4f

udev: override new udev default timeout of 30s to original 3min

New versions of udev changed the default event timeout to 30s
from original 3min. This causes problems with LVM processes that
starve because of the IO load caused by some LVM actions (e.g.
mirror/raid synchronization).

Reinstate the 3min udev timeout for now until we optimize this
in a way that even the 30s timeout is sufficient.

RAID: Make RAID single-machine-exclusive capable in a cluster

Creation, deletion, [de]activation, repair, conversion, scrubbing
and changing operations are all now available for RAID LVs in a
cluster - provided that they are activated exclusively.

The code has been changed to ensure that no LV or sub-LV activation
is attempted cluster-wide.  This includes the often overlooked
operations of activating metadata areas for the brief time it takes
to clear them.  Additionally, some 'resume_lv' operations were
replaced with 'activate_lv_excl_local' when sub-LVs were promoted
to top-level LVs for removal, clearing or extraction.  This was
necessary because it forces the appropriate renaming actions the
occur via resume in the single-machine case, but won't happen in
a cluster due to the necessity of acquiring a lock first.

The *raid* tests have been updated to allow testing in a cluster.
For the most part, this meant creating devices with '-aey' if they
were to be converted to RAID.  (RAID requires the converting LV to
be EX because it is a condition of activation for the RAID LV in
a cluster.)

udev: fix pvscan --cache -aay to trigger on relevant events

This patch fixes the way the special devices are handled
(special in this context means that they're not usable
after the usual ADD event like other generic devices):

  - DM and MD devices are pvscanned only when they are just set up.
    This is the first CHANGE event that makes the device  usable
    (the DM_UDEV_PRIMARY_SOURCE_FLAG is set for DM and the
     md/array_state sysfs attribute is present for MD).
    Whether the device is activated is remembered via
    DM_ACTIVATED (for DM) and LVM_MD_PV_ACTIVATED (for MD)
    udev environment variable. This is then used to decide
    whether we should fire the pvscan on ADD event to
    support coldplugging. For any (artificial) ADD event
    generated during coldplug, the device must be already
    set up properly to fire the pvscan on it.

  - Similar for loop devices. For loop devices, only CHANGE
    events are relevant (so there's a CHANGE after the loop
    device is set up as well as detached). Whether the loop
    has just been activated is detected via loop/backing_file
    sysfs attribute presence. The activation state is remembered
    via LVM_LOOP_PV_ACTIVATED udev environment variable.

  - Do not pvscan multipath device components (underlying paths).

  - Do not pvscan RAID device components.

  - Also, set LVM_SCANNED="1" udev environment variable for
    debug purposes (it's visible in the lvmdump -u that takes
    the current udev database). This variable is set once
    the pvscan is triggered.

The table below summarises when the pvscan is triggered
(marked with X, X* means fire only if the special dev is properly set up):

      | real ADD | real CHANGE | artificial ADD | artificial CHANGE | remove
=============================================================================
DM    |          |      X      |       X*       |                   |   X
MD    |          |      X      |       X*       |                   |
loop  |          |      X      |       X*       |                   |
other |    X     |             |       X        |                   |   X

udev: DM_ID_FS_TYPE should be ID_FS_TYPE when comparing with old value

Misc/RAID: Enable resume_lv to handle some renaming conflicts.

When images and their associated metadata are removed from a RAID1 LV,
the remaining sub-LVs are "shifted" down to fill the gaps.  For
example, if there is a 3-way mirror:
[0][1][2]
and we remove device#0, the devices will be shifted down
[1][2]
and renamed.
[0][1]

This can create a problem for resume_lv (specifically,
dm_tree_activate_children) during the renaming process though.  This
is because it will attempt to rename the higher indexed sub-LVs first
and find that it cannot because there are currently other sub-LVs with
that name.  The solution is to check for a conflicting name before
attempting to rename.  If a conflict is found and that conflicting
sub-LV is also in the process of renaming, we can defer the current
rename until the conflicting sub-LV has renamed and cleared the
conflict.

Now that resume_lv can handle these types of rename conflicts, we can
remove the workaround in RAID that was attempting to resume a RAID1
LV from the bottom-up in order to force a proper rename in assending
order before attempting a resume on the top-level LV.  This "hack"
only worked for single machine use-cases of LVM.  Clearing this up
paves the way for exclusive activation of RAID LVs in a cluster.

udev: also inform lvmetad about lost LVM1 PV label

Addendum to 4d3b5724e0b51782000a45027de00e0fed1c9833
which covered only LVM2 PV labels.

cleanup: drop within comment gcc warning

toollib.c:69:24: warning: "/*" within comment

test: timeout when no write happens since last written line

Change current test abort after 3 minutes, to abort after 3 minutes
without written output line.

deactivate: drop readahead calc in deactivation

Skip readahead when device will be deactivated.

thin: validation catch multiseg thin pool/volumes

Multisegment thin pools and volumes are not supported.
Catch such error code path early.

thin: fix monitoring of thin pool volume

Properly skip unmonitoring of thin pool volume in deactivation code
path. Code makes sure if there is just any thin pool user
it stays monitored with all its resources.

thin: fix resize of stacked thin pool volume

When the pool is created from non-linear target the more complex rules
have to be used and stacking needs to properly decode args for _tdata
LV. Also proper allocation policies are being used according to those
set in lvm2 metadata for data and metadata LVs.

Also properly check for active pool and extra code to active it
temporarily.

With this fix it's now possible to use:

lvcreate -L20 -m2 -n pool vg  --alloc anywhere
lvcreate -L10 -m2 -n poolm vg --alloc anywhere
lvconvert --thinpool vg/pool --poolmetadata vg/poolm

lvresize -L+10 vg/pool

test: Add the 64b fc17 kernel to the mirror recovery blacklist.

toollib: tweak background forking

Log what is forked and replace #if 1 with DEBUG_CHILD.

logging: Write Completed message before resetting.

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.

test: Include tests that timed out in the final summary.

pvmove: Skip pvmove of RAID, thin, snapshot, origin, and mirror LVs in cluster

pvmove of the above types should only have been enabled in single machine
mode.

test: Fix a spurious failure in skip_if_mirror_recovery_broken.

TEST: pvmove-all-segtypes.sh should not be run in a cluster

reinstate: commit 82d83a01ce2cac77fec2e9b763061fbfb5f01ce8

It now works as supposed. The source of the problem is fixed
by previous commit d2d6a9da52e04f28e1916bcea3f9fda356b6df29.

tools: add -b/--background for pvscan --cache -aay

Udev daemon has recently introduced a limit on the number of udev
processes (there was no limit before). This causes a problem
when calling pvscan --cache -aay in lvmetad udev rules which
is supposed to activate the volumes. This activation is itself
synced with udev and so it waits for the activation to complete
before the pvscan finishes. The event processing can't continue
until this pvscan call is finished.

But if we're at the limit with the udev process count, we can't
instatiate any more udev processes, all such events are queued
and so we can't process the lvm activation event for which the
pvscan is waiting.

Then we're in a deadlock since the udev process with the
pvscan --cache -aay call waits for the lvm activation udev
processing to complete, but that will never happen as there's
this limit hit with the number of udev processes.

The process with pvscan --cache -aay actually times out eventually
(3min or 30sec, depends on the version of udev).

This patch makes it possible to run the pvscan --cache -aay
in the background so the udev processing can continue and hence
we can avoid the deadlock mentioned above.

test: Skip tests involving mirror recovery on known bad kernels.

pvscan: show -aay with --cache for help

revert: commit 82d83a01ce2cac77fec2e9b763061fbfb5f01ce8

The commit 82d83a01ce2cac77fec2e9b763061fbfb5f01ce8
"autoactivation: refresh existing VG before autoactivation"
causes problems (dangling udev_sync cookies, slow processing
of the pvscan --cache --major --minor call from udev rules)
when the autoactivation handler is run in parallel on
several PVs that belong to the same VG. Revert this patch
until the exact source of the problem is found and then
properly fixed and handled.

tests: test pvmove behavior after restart

Simulate crash of the system and restarted pvmove after next VG
activation.

Test is catching regression introduced in 2.02.99 for partial tree
creation changes.

tests: add delay_dev

Function to create slower responsive device.

Useful for testing things which needs to happen something during on
going operation - with  'delayed' device - much smaller sizes of devices
are needed and its much more deterministic (though still not optimal)

libdm: new name can't be empty

Do not allow passing '' names to kernel.

This test was missing also in kernel, so it has allowed
to create device with '' name.  This then confused dmsetup tool,
since such name is unexpected and unsupported. To remove
such name from table, user has to use -j -m to specify which device
should be removed.

This patch fixes the posibility to run this operation:

dmsetup rename existingdev ''

after this operation commands like  'dmsetup table' are failing.
This patch prohibits to use such name.

test: fix process-each-duplicate-vgnames

After enable_dev, the following commands were not
consistently seeing the pv on it.

Alasdair explained, "whenever enabling/disabling devs
outside the tools (and you aren't trying to test how
the tools cope with suddenly appearing/disappering
devices) use "vgscan""

man: lvmdump -u -l

toolcontext: Only reopen stdin if readable.

Don't fail when running lvm commands under versions of nohup that set
up stdin as O_WRONLY!

activation: Fix segfault with inactive pvmove LV.

Set flag to avoid recursion back through an inactive pvmove LV when
populating deptree.

systemd: lvm2-activation-generator: remove default dir if args not specified and require all args to be given

Remove default "/tmp" as destination directory if no args
specified for lvm2-activation-generator. Require all the
args to be specified directly for proper functionality.

man: lvmdump: add doc for -l and -u

test: Set the timeout to 3 minutes (was 5s accidentally).

test: Add a new "check_full" target, which also tests with real /dev.

The original "check" target stays confined to a local device directory, while
check_full does 6 flavours, 3 with a local device directory and 3 with the
global /dev directory (the latter are prefixed with "s" for
"system"). I.e.: normal, cluster, lvmetad, snormal, scluster, slvmetad.

test: Check for flavoured variables earlier.

This is necessary to make LVM_TEST_DEVDIR flavourable, and in turn have flavours
that use the global /dev (which can in turn be managed by udev).

test: Remove a redundant drain() from the timeout path.

test: Make timeouts a little more robust & verbose.

TEST: Add a timeout to the harness, killing tests after 2 minutes.

TEST: Add tests for lvchange actions of RAID under thin

Patch includes RAID1,4,5,6,10 tests for:
- setting writemostly/writebehind
* syncaction changes (i.e. scrubbing operations)
- refresh (i.e. reviving devices after transient failures)
- setting recovery rate (sync I/O throttling)
while the RAID LVs are under a thin-pool (both data and metadata)

* not fully tested because I haven't found a way to force bad
  blocks to be noticed in the testsuite yet.  Works just fine
  when dealing with "real" devices.

test: pvmove tests for all the different segment types.

Test moving linear, mirror, snapshot, RAID1,5,10, thinpool, thin
and thin on RAID.  Perform the moves along with a dummy LV and
also without the dummy LV by specifying a logical volume name as
an argument to pvmove.

pvmove:  Allow moving snapshot/origin.  Disallow converting and merging LVs

The patch allows the user to also pvmove snapshots and origin logical
volumes.  This means pvmove should be able to move all segment types.
I have, however, disallowed moving converting or merging logical volumes.

pvmove: Fix inability to specify LV name when moving RAID, mirror, or thin LV

Top-level LVs (like RAID, mirror or thin) are ignored when determining which
portions of an LV to pvmove.  If the user specified the name of an LV to
move and it was one of the above types, it would be skipped.  The code would
never move on to check whether its sub-LVs needed moving because their names
did not match what the user specified.

The solution is to check whether a sub-LVs is part of the LV whose name was
specified by the user - not just if there was a name match.

WHATS_NEW: for 4d3b5724e0b51782000a45027de00e0fed1c9833

udev: inform lvmetad about lost PV label

In stacked environment where we have a PV layered on top of a
snapshot LV and then removing the LV, lvmetad still keeps information
about the PV:

[0] raw/~ $ pvcreate /dev/sda
  Physical volume "/dev/sda" successfully created
[0] raw/~ $ vgcreate vg /dev/sda
  Volume group "vg" successfully created
[0] raw/~ $ lvcreate -L32m vg
  Logical volume "lvol0" created
[0] raw/~ $ lvcreate -L32m -s vg/lvol0
  Logical volume "lvol1" created
[0] raw/~ $ pvcreate /dev/vg/lvol1
  Physical volume "/dev/vg/lvol1" successfully created
[0] raw/~ $ lvremove -ff vg/lvol1
  Logical volume "lvol1" successfully removed
[0] raw/~ $ pvs
  No device found for PV BdNlu2-7bHV-XcIp-mFFC-PPuR-ef6K-yffdzO.
  PV         VG         Fmt  Attr PSize   PFree
  /dev/sda   vg         lvm2 a--  124.00m 92.00m
[0] raw/~ $ pvscan --cache --major 253 --minor 3
  Device 253:3 not found. Cleared from lvmetad cache.

This is because of the reactivation that is done just before
snapshot removal as part of the process (vg/lvol1 from the example above).
This causes a CHANGE event to be generated, but any scan done
on the LV does not see the original data anymore (in this case
the stacked PV label on top) and consequently the ID_FS_TYPE="LVM2_member"
(provided by blkid scan) is not stored in udev db anymore for the LV.
Consequently, the pvscan --cache is not run anymore as the dev is not
identified as LVM PV by the "LVM2_member" id - lvmetad loses this info
and still keeps records about the PV.

We can run into a very similar problem with erasing the PV label directly:

[0] raw/~ $ lvcreate -L32m vg
  Logical volume "lvol0" created
[0] raw/~ $ pvcreate /dev/vg/lvol0
  Physical volume "/dev/vg/lvol0" successfully created
[0] raw/~ $ dd if=/dev/zero of=/dev/vg/lvol0 bs=1M
dd: error writing '/dev/vg/lvol0': No space left on device
33+0 records in
32+0 records out
33554432 bytes (34 MB) copied, 0.380921 s, 88.1 MB/s
[0] raw/~ $ pvs
  PV            VG         Fmt  Attr PSize   PFree
  /dev/sda      vg         lvm2 a--  124.00m 92.00m
  /dev/vg/lvol0            lvm2 a--   32.00m 32.00m
[0] raw/~ $ pvscan --cache --major 253 --minor 2
  No PV label found on /dev/vg/lvol0.

This patch adds detection of this change from ID_FS_LABEL="LVM2_member"
to ID_FS_LABEL="<whatever_else>" and hence informing the lvmetad
about PV being gone.

thin: support lvchange for data and metadata

Support lvchange operation on stacked thin pool data and metadata
volumes.

test: add process-each-vg and process-each-lv

These test the toollib functions that select
vgs/lvs to process based on command line args:
empty, vg name(s), lv names(s), vg tag(s),
lv tags(s), and combinations of all.

test: add process-each-duplicate-vgnames

Test that vgs shows both vgs when two vgs
exist with the same name but different uuids.

test: add vg-name-from-env

vg name should come from env var LVM_VG_NAME
for commands that take vg name and lv name,
but vg name is not specified on command line.

misc: make lv_is_on_pv use for_each_sub_lv to walk LV tree

Make lv_is_on_pv use for_each_sub_lv to walk the LV tree.  This
reduces code duplication.

pvmove: Ability to move thin volumes

The previous commit was missing the code to allow moving thin
volumes.

pvmove: Add support for RAID, mirror, and thin

This patch allows pvmove to operate on RAID, mirror and thin LVs.
The key component is the ability to avoid moving a RAID or mirror
sub-LV onto a PV that already has another RAID sub-LV on it.
(e.g. Avoid placing both images of a RAID1 LV on the same PV.)

Top-level LVs are processed to determine which PVs to avoid for
the sake of redundancy, while bottom-level LVs are processed
to determine which segments/extents to move.

This approach does have some drawbacks.  By eliminating whole PVs
from the allocation list, we might miss the opportunity to perform
pvmove in some senarios.  For example, if we have 3 devices and
a linear uses half of the first, a RAID1 uses half of the first and
half of the second, and a linear uses half of the third (FIGURE 1);
we should be able to pvmove the first device (FIGURE 2).
FIGURE 1:
        [ linear ] [ -RAID- ] [ linear ]
        [ -RAID- ] [        ] [        ]

FIGURE 2:
        [  moved ] [ -RAID- ] [ linear ]
        [  moved ] [ linear ] [ -RAID- ]
However, the approach we are using would eliminate the second
device from consideration and would leave us with too little space
for allocation.  In these situations, the user does have the ability
to specify LVs and move them one at a time.

Thin: Make 'lv_is_on_pv(s)' work with thin types

The pool metadata LV must be accounted for when determining what PVs
are in a thin-pool.  The pool LV must also be accounted for when
checking thin volumes.

This is a prerequisite for pvmove working with thin types.

Misc: Make get_pv_list_for_lv() available to more than just RAID

The function 'get_pv_list_for_lv' will assemble all the PVs that are
used by the specified LV.  It uses 'for_each_sub_lv' to traverse all
of the sub-lvs which may compose it.

conf: more comments about use_lvmetad + autoactivation relation

systemd: lvm2-activation-generator: report only error otherwise be silent

Do not print success status for lvm2-activation-generator:

  "LVM: Activation generator successfully completed."
  "LVM: Logical Volume autoactivation enabled." (if use_lvmetad=1)

Though this information is quite useful during boot, it may
be confusing for users if it happens anytime later and it
actually happens if systemd reloads. This is usually on package
update to update the systemd state and load any new units that are
newly installed in the system. The systemd reload is global and
so any existing generators are rerun at that moment too.

filter-mpath: remove superfluous error message about mpath major not equal to dm major

This is a regression caused by commit 3bd90488545a4ad5374b4e0f1daba6cf16ae6ae8.
The error message added with that commit "mpath major %d is not dm major %d" is
superfluous.

When scanning for mpath components, we're looking for a parent device.
But this parent device is not necessarily an mpath device (so the dm device)
if it exists - it can be any other device layered on top (e.g. an MD RAID device).

cmirrord: Prevent secondary checkpoints from corrupting bitmaps

The bug addressed by this patch manifested itself during testing
by showing a mirror that never became 'in-sync' after creation.
The bug is isolated to distributions that do not have support
for openAIS checkpointing (i.e. > RHEL6, > F16).

When a node joins a group that is managing a mirror log, the other
machines in the group send it a checkpoint representing the current
state of the bitmap.  More than one machine can send a checkpoint,
but only the initial one should be imported.  Once the bitmap state
has been imported from the initial checkpoint, operations (such
as resync, mark, and clear operations) can begin.  When subsequent
checkpoints are allowed to be imported, it has the effect of erasing
all the log operations between the initial checkpoint and the ones
that follow.

When cmirrord was updated to handle the absence of openAIS
checkpointing (commit 62e38da133d9801cdf36b0f2aaec615ce14b9000),
the new import_checkpoint() function failed to honor the 'no_read'
parameter.  This parameter was designed to avoid reading all but
the initial checkpoint.  Honoring this parameter has solved the
issue of corrupting bitmap data with secondary checkpoints.

dumpconfig: also mention profilable type if giving hint about known types

dmsetup: display any message output from kernel

Recent kernels allow messages to respond with a string.
Add dm_task_get_message_response() to libdevmapper to perform some
basic sanity checks and return this.
Have 'dmsetup message' display any response.

DM statistics will make extensive use of this.

(From Mikulas.)

udev: fix lvmetad rules to not ignore loop device configuration

If loop device is first configured on systems where /dev/loop-control
is used to dynamically create the loop device itself, there's an
ADD+CHANGE even generated. But next time the existing /dev/loop[0-9]*
is reused, there's only a CHANGE event since the device representing
it is already present in kernel (so no ADD event in this case).

We can't ignore this CHANGE event for loop devices! This is a regression
caused by 756bcabbfe297688ba240a880bc2b55265ad33f0. We already had
a similar problem with MD devices which was fixed by
2ac217d408470dcecb69b83d9cbf7a254747fa5b (but that one was
only an intra-release fix).

fix: ambiguity in log_sys_error call from previous commit

libdm-common.c:883:42: warning: pointer/integer type mismatch in conditional expression

define log_sys_error(x, y) log_err("%s%s%s failed: %s", y, *y ? ": " : "", x, strerror(errno))

So the "y" which was 'path ? : "SELinux context reset"' from
previous commit did not quite fit the other "? :" in the log_sys_macro.

fix: some issues reported by coverity

  - null_fd resource leak on error path in _reopen_fd_null fn
  - dead code in verify_message in clvmd code
  - dead code in _init_filter_components in toolcontext code
  - null dereference in dm_prepare_selinux_context on error path if
    setfscreatecon fails while resetting SELinux context

systemd: use LVM_PATH instead of hardcoded value in activation generator

lvm2app: lvm_list_pvs_free seg. fault when no PVs

When the system has no PVs we don't have access to
the cmd pointer and it remains NULL which causes
a seg. fault when we try to free the VG lock.

Signed-off-by: Tony Asleson <tasleson@redhat.com>

test: Fix false positives due to open devices

Something is rather randomly keeping devices open. As it is a known udev
feature, waiting for transaction may (or may not) help.

autoactivation: refresh existing VG before autoactivation

When autoactivating a VG, there could be an existing VG with exactly
the same PV UUIDs. The PVs could be reappeared after previous
loss/disconnect (for example disconnecting and reconnecting iscsi).

Since there's no "autodeactivation" yet, the mappings for the LVs
from the VG were left in the system even if the device was disconnected.
These mappings also hold the major:minor of the underlying device.
So if the device reappears, it is assigned a different major:minor
pair (...and kernel name). We need to cope with this during
autoactivation so any existing mappings are corrected for any changes.
The VG refresh does that (the vgchange --refresh functionality) -
call this before VG autoactivation.

(If the VG does not exist yet, the VG refresh is NOP)

WHATS_NEW: for 0da72743ca46ae9f8185cd12d5c78b3c2b801872

filters: check for mpath before opening devs

Split out the partitioned device filter that needs to open the device
and move the multipath filter in front of it.

When a device is multipathed, sending I/O to the underlying paths may
cause problems, the most obvious being I/O errors visible to lvm if a
path is down.

Revert the incorrect <backtrace> messages added when a device doesn't
pass a filter.

Log each filter initialisation to show sequence.

Avoid duplicate 'Using $device' debug messages.