activate: add lv_layer function

Add function to return layer name for LV.

libdm: fix segault for truncated string token.

This patch fixes problem reported here:

https://www.redhat.com/archives/dm-devel/2013-January/msg00311.html

Fixing it by separating function for duplicating string token.

---
When /etc/lvm/lvm.conf is truncated at the first '"' of a line, all LVM
utilities crash with a segfault.

The segfault only seems to occur if the last character is the first '"'
(double quote) of a line. If you truncate it at any other point, lvm
detects the error and report parse error

lvm.conf ends like this.

$hexdump -C lvm.conf
....
69 72 20 3d 20 22 2f 64  65 76 22 0a 0a 0a 20 20  |ir = "/dev"...  |
20 20 23 20 41 6e 20 61  72 72 61 79 20 6f 66 20  |  # An array of |
64 69 72 65 63 74 6f 72  69 65 73 20 74 68 61 74  |directories that|
20 63 6f 6e 74 61 69 6e  20 74 68 65 20 64 65 76  | contain the dev|
69 63 65 20 6e 6f 64 65  73 20 79 6f 75 20 77 69  |ice nodes you wi|
73 68 0a 20 20 20 20 23  20 74 6f 20 75 73 65 20  |sh.    # to use |
77 69 74 68 20 4c 56 4d  32 2e 0a 20 20 20 20 73  |with LVM2..    s|
63 61 6e 20 3d 20 5b 20  22 2f 78 22 2c 0a 20 20  |can = [ "/x",.  |
20 20 20 20 20 20 20 20  20 20 20 22              | "|
...

Reported-by: dongmao zhang <dmzhang suse com>

cleanup: postpone lv_is_thin_volume check

Code move to make it easier to follow and
call _add_dev_to_dtree() in the separate if() branch
for thin volumes.

WHATS_NEW:  Better description of previous change

RAID:  Improve 'lvs' attribute reporting of RAID LVs and sub-LVs

There are currently a few issues with the reporting done on RAID LVs and
sub-LVs.  The most concerning is that 'lvs' does not always report the
correct failure status of individual RAID sub-LVs (devices).  This can
occur when a device fails and is restored after the failure has been
detected by the kernel.  In this case, 'lvs' would report all devices are
fine because it can read the labels on each device just fine.
Example:
[root@bp-01 lvm2]# lvs -a -o name,vg_name,attr,copy_percent,devices vg
  LV            VG   Attr      Cpy%Sync Devices
  lv            vg   rwi-a-r--   100.00 lv_rimage_0(0),lv_rimage_1(0)
  [lv_rimage_0] vg   iwi-aor--          /dev/sda1(1)
  [lv_rimage_1] vg   iwi-aor--          /dev/sdb1(1)
  [lv_rmeta_0]  vg   ewi-aor--          /dev/sda1(0)
  [lv_rmeta_1]  vg   ewi-aor--          /dev/sdb1(0)

However, 'dmsetup status' on the device tells us a different story:
  [root@bp-01 lvm2]# dmsetup status vg-lv
  0 1024000 raid raid1 2 DA 1024000/1024000

In this case, we must also be sure to check the RAID LVs kernel status
in order to get the proper information.  Here is an example of the correct
output that is displayed after this patch is applied:
[root@bp-01 lvm2]# lvs -a -o name,vg_name,attr,copy_percent,devices vg
  LV            VG   Attr      Cpy%Sync Devices
  lv            vg   rwi-a-r-p   100.00 lv_rimage_0(0),lv_rimage_1(0)
  [lv_rimage_0] vg   iwi-aor-p          /dev/sda1(1)
  [lv_rimage_1] vg   iwi-aor--          /dev/sdb1(1)
  [lv_rmeta_0]  vg   ewi-aor-p          /dev/sda1(0)
  [lv_rmeta_1]  vg   ewi-aor--          /dev/sdb1(0)

The other case where 'lvs' gives incomplete or improper output is when a
device is replaced or added to a RAID LV.  It should display that the RAID
LV is in the process of sync'ing and that the new device is the only one
that is not-in-sync - as indicated by a leading 'I' in the Attr column.
(Remember that 'i' indicates an (i)mage that is in-sync and 'I' indicates
an (I)mage that is not in sync.)  Here's an example of the old incorrect
behaviour:
[root@bp-01 lvm2]# lvs -a -o name,vg_name,attr,copy_percent,devices vg
  LV            VG   Attr      Cpy%Sync Devices
  lv            vg   rwi-a-r--   100.00 lv_rimage_0(0),lv_rimage_1(0)
  [lv_rimage_0] vg   iwi-aor--          /dev/sda1(1)
  [lv_rimage_1] vg   iwi-aor--          /dev/sdb1(1)
  [lv_rmeta_0]  vg   ewi-aor--          /dev/sda1(0)
  [lv_rmeta_1]  vg   ewi-aor--          /dev/sdb1(0)
[root@bp-01 lvm2]# lvconvert -m +1 vg/lv; lvs -a -o name,vg_name,attr,copy_percent,devices vg
  LV            VG   Attr      Cpy%Sync Devices
  lv            vg   rwi-a-r--     0.00 lv_rimage_0(0),lv_rimage_1(0),lv_rimage_2(0)
  [lv_rimage_0] vg   Iwi-aor--          /dev/sda1(1)
  [lv_rimage_1] vg   Iwi-aor--          /dev/sdb1(1)
  [lv_rimage_2] vg   Iwi-aor--          /dev/sdc1(1)
  [lv_rmeta_0]  vg   ewi-aor--          /dev/sda1(0)
  [lv_rmeta_1]  vg   ewi-aor--          /dev/sdb1(0)
  [lv_rmeta_2]  vg   ewi-aor--          /dev/sdc1(0)                            ** Note that all the images currently are marked as 'I' even though it is
   only the last device that has been added that should be marked.

Here is an example of the correct output after this patch is applied:
[root@bp-01 lvm2]# lvs -a -o name,vg_name,attr,copy_percent,devices vg
  LV            VG   Attr      Cpy%Sync Devices
  lv            vg   rwi-a-r--   100.00 lv_rimage_0(0),lv_rimage_1(0)
  [lv_rimage_0] vg   iwi-aor--          /dev/sda1(1)
  [lv_rimage_1] vg   iwi-aor--          /dev/sdb1(1)
  [lv_rmeta_0]  vg   ewi-aor--          /dev/sda1(0)
  [lv_rmeta_1]  vg   ewi-aor--          /dev/sdb1(0)
[root@bp-01 lvm2]# lvconvert -m +1 vg/lv; lvs -a -o name,vg_name,attr,copy_percent,devices vg
  LV            VG   Attr      Cpy%Sync Devices
  lv            vg   rwi-a-r--     0.00 lv_rimage_0(0),lv_rimage_1(0),lv_rimage_2(0)
  [lv_rimage_0] vg   iwi-aor--          /dev/sda1(1)
  [lv_rimage_1] vg   iwi-aor--          /dev/sdb1(1)
  [lv_rimage_2] vg   Iwi-aor--          /dev/sdc1(1)
  [lv_rmeta_0]  vg   ewi-aor--          /dev/sda1(0)
  [lv_rmeta_1]  vg   ewi-aor--          /dev/sdb1(0)
  [lv_rmeta_2]  vg   ewi-aor--          /dev/sdc1(0)
** Note only the last image is marked with an 'I'.  This is correct and we can
   tell that it isn't the whole array that is sync'ing, but just the new
   device.

It also works under snapshots...
[root@bp-01 lvm2]# lvs -a -o name,vg_name,attr,copy_percent,devices vg
  LV            VG   Attr      Cpy%Sync Devices
  lv            vg   owi-a-r-p    33.47 lv_rimage_0(0),lv_rimage_1(0),lv_rimage_2(0)
  [lv_rimage_0] vg   iwi-aor--          /dev/sda1(1)
  [lv_rimage_1] vg   Iwi-aor-p          /dev/sdb1(1)
  [lv_rimage_2] vg   Iwi-aor--          /dev/sdc1(1)
  [lv_rmeta_0]  vg   ewi-aor--          /dev/sda1(0)
  [lv_rmeta_1]  vg   ewi-aor-p          /dev/sdb1(0)
  [lv_rmeta_2]  vg   ewi-aor--          /dev/sdc1(0)
  snap          vg   swi-a-s--          /dev/sda1(51201)

RAID:  Cache previous results of lv_raid_dev_health for future use

We can avoid many dev_manager (ioctl) calls by caching the results of
previous calls to lv_raid_dev_health.  Just considering the case where
'lvs -a' is called to get the attributes of a RAID LV and its sub-lvs,
this function would be called many times.  (It would be called at least
7 times for a 3-way RAID1 - once for the health of each sub-LV and once
for the health of the top-level LV.)  This is a good idea because the
sub-LVs are processed in groups along with their parent RAID LV and in
each case, it is the parent LV whose status will be queried.  Therefore,
there only needs to be one trip through dev_manager for each time the
group is processed.

RAID:  Add RAID status accessibility functions

Similar to the way thin* accesses its kernel status, we add a method
for RAID to grab the various values in its status output without the
higher levels (LVM) having to understand how to parse the output.
Added functions include:
        - lib/activate/dev_manager.c:dev_manager_raid_status()
          Pulls the status line from the kernel

        - libdm/libdm-deptree.c:dm_get_status_raid()
          Parses status line and puts components into dm_status_raid struct

        - lib/activate/activate.c:lv_raid_dev_health()
          Accesses dm_status_raid to deliver raid dev_health string

The new structure and functions can provide a more unified way to access
status information.  ('lv_raid_percent' could switch to using these
functions, for example.)

Test (RAID):  Test for RAID10 activations when devices are missing

Test the fix for bug 889358.  RAID10 had been failing to activate when
there were devices that had failed in more than one mirror set.

blkdeactivate: prevent trying to unmount the same mountpoint more times

An addendum to previous commit 1052863a1b35f7488758c78b3a9ebef5c63392bc.

blkdeactivate: fix handling of nested mountpoints and mangled mount paths.

If there was a nested mountpoint inside an existing mount path,
blkdeactivate could fail to unmount such a mountpoint as it
needs to deactivate the deepest path first and continue upwards.

For example the simplest reproducer:

[root@rhel6-a ~]# lsblk
NAME                        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                           8:0    0    4G  0 disk
|-vg-lvol0 (dm-2)           253:2    0   32M  0 lvm  /mnt/a
`-vg-lvol1 (dm-3)           253:3    0   32M  0 lvm  /mnt/a/b

Before this patch:

[root@rhel6-a ~]# blkdeactivate -u
Deactivating block devices:
  UMOUNT: unmounting vg-lvol0 (dm-2) mounted on /mnt/a
umount: /mnt/a: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))
  UMOUNT: unmounting vg-lvol1 (dm-3) mounted on /mnt/a/b
  LVM: deactivating Logical Volume vg/lvol1

(deactivation of vg/lvol0 is skipped as /mnt/a that is on lvol0
can't be unmounted - it still has /mnt/a/b as nested mountpoint!)

With this patch applied:

[root@rhel6-a ~]# blkdeactivate -u
Deactivating block devices:
  UMOUNT: unmounting vg-lvol1 (dm-3) mounted on /mnt/a/b
  UMOUNT: unmounting vg-lvol0 (dm-2) mounted on /mnt/a
  LVM: deactivating Logical Volume vg/lvol0
  LVM: deactivating Logical Volume vg/lvol1

===

Also, this patch contains a fix for processing mangled mount paths:

[root@rhel6-a ~]# lsblk
NAME                        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                           8:0    0    4G  0 disk
`-vg-lvol0 (dm-2)           253:2    0   32M  0 lvm  /mnt/x y z

[root@rhel6-a ~]# lsblk -r
vg-lvol0 253:2 0 32M 0 lvm /mnt/x\x20y\x20z

(the mount path is mangled with \xNN that is visible in raw
lsblk output only and which is used in blkdeactive as well)

Before this patch:

[root@rhel6-a ~]# blkdeactivate -u
Deactivating block devices:
  umount: /mnt/x\x20y\x20z: not found

After this patch applied:

[root@rhel6-a ~]# blkdeactivate -u
Deactivating block devices:
  UMOUNT: unmounting vg-lvol0 (dm-2) mounted on /mnt/x\x20y\x20z
  LVM: deactivating Logical Volume vg/lvol0

locales: use higher prio LC_ALL variable

For reseting locale environment into significantly less memory
consuming version 'C' - use LC_ALL instead of LANG since it has
higher priority in locale settings.

Otherwise we may observe whole locale-archive which might be
over 100MB on i.e. Fedora systems locked in memory with
some daemons.

Update WHATS_NEW.

lvmetad: Call _lvmetad_handle_reply in lvmetad_vg_lookup.

lvmetad: Fix a race in metadata update.

The idea is to avoid a period when an existing VG is not mapped to either the
old or the new name. (Note that the brief "blackout" was present even if the
name did not actually change.) We instead allow a brief overlap of a VG existing
under both names, i.e. a query for a VG might succeed but before a lock is
acquired the VG disappears.

dmeventd: close dmeventd FIFO FDs on exec (add FD_CLOEXEC).

whatsnew

filters: add scm devices

Fix this:
pvcreate /dev/scma
  Device /dev/scma not found (or ignored by filtering).

Reported-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>

logging: classify log_debug messages

Place most log_debug() messages into a class.

logging: add debug classes

Add log/debug_classes to lvm.conf to allow debug messages to be
classified and filtered at runtime.

The dm_errno field is only used by log_error(), so I've redefined it
for log_debug() messages to hold the message class.

By default, all existing messages appear, but we can add categories that
generate high volumes of data, such as logging all traffic to/from
lvmetad.

lvmetad: fix format1 updates

fmt1 doesn't have a separate commit function: updates take effect
immediately vg_write is called, so we must update lvmetad at this
point if we're going to go on and ask lvmetad for the VG metadata
again before calling the commit function (though that's probably an
unsupported and pointless thing to do anyway as the client must
already have that data and it cannot have changed because it's locked
and with devs suspended we shouldn't be communicating with lvmetad;
so when that's fixed properly, this fix here can be reverted).

This problem showed up as an internal error when lvremoving an LVM1
snapshot.

> Internal error: LV snap1 (00000000000000000000000000000001) missing from preload metadata

https://bugzilla.redhat.com/891855

lvmetad: add basic client-side debug logging

First attempt at showing precisely what use any command is making of
lvmetad in the -vvvv trace information.

lvmetad: rename device vars and move _token_update

Move _token_update() to avoid the need for _lvmetad_send prototype.

Use 'dev' consistently for a struct device * variable.
Use 'devno' for a dev_t.

libdaemon: add logging to daemon_open

Log all conditions encountered in daemon_open().

Only store errno when known to be set.

lvmetad: improve client logging when connecting

Rename lvmetad_warning() to lvmetad_connect_or_warn().

Log all connection attempts on the client side, whether successful or not.

Reduce some nesting and remove a redundant assertion.

lvmetad: lvm depends on libdaemonclient.a

Rebuild lvm binary if libdaemonclient.a changes.

pvscan: synchronize with udev if pvscan --cache is used.

We need to call sync_local_dev_names directly as pvscan uses
VG_GLOBAL lock and this one *does not* cause the synchronization
(sync_dev_names) to be called on unlock (VG_GLOBAL is not a real VG):

define unlock_vg(cmd, vol)
  do { \
    if (is_real_vg(vol)) \
      sync_dev_names(cmd); \
    (void) lock_vol(cmd, vol, LCK_VG_UNLOCK); \
  } while (0)

Without this fix, we end up without udev synchronization for the
pvscan --cache (mainly for -aay that causes the VGs/LVs to be
autoactivated) and also udev synchronization cookies are then left
in the system since they're not managed properly (code before sets
up udev sync cookies, but we have to call dm_udev_wait at least once
after that to do the wait and cleanup).

activation: fix autoactivation to not trigger on each PV change

Before, the pvscan --cache -aay was called on each ADD and CHANGE
uevent (for a device that is not a device-mapper device) and each CHANGE
event (for a PV that is a device-mapper device).

This causes troubles with autoactivation in some cases as CHANGE event
may originate from using the OPTION+="watch" udev rule that is defined
in 60-persistent-storage.rules (part of the rules provided by udev
directly) and it's used for all block devices
(except fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md* devices). For example, the
following sequence incorrectly activates the rest of LVs in a VG if one
of the LVs in the VG is being removed:

[root@rhel6-a ~]# pvcreate /dev/sda
  Physical volume "/dev/sda" successfully created

[root@rhel6-a ~]# vgcreate vg /dev/sda
  Volume group "vg" successfully created

[root@rhel6-a ~]# lvcreate -l1 vg
  Logical volume "lvol0" created

[root@rhel6-a ~]# lvcreate -l1 vg
  Logical volume "lvol1" created

[root@rhel6-a ~]# vgchange -an vg
  0 logical volume(s) in volume group "vg" now active

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log
Cpy%Sync Convert
  lvol0   vg        -wi------   4.00m
  lvol1   vg        -wi------   4.00m

[root@rhel6-a ~]# lvremove -ff vg/lvol1
  Logical volume "lvol1" successfully removed

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log
Cpy%Sync Convert
  lvol0   vg        -wi-a----   4.00m

...so the vg was deactivated, then lvol1 removed, and we end up with
lvol1 removed (which is ok) BUT with lvol0 activated (which is wrong)!!!
This is because after lvol1 removal, we need to write metadata to the
underlying device /dev/sda and that causes the CHANGE event to be
generated (because of the WATCH udev rule set on this device) and this
causes the pvscan --cache -aay to be reevaluated.

We have to limit this and call pvscan --cache -aay to autoactivate
VGs/LVs only in these cases:

 --> if the *PV is not a dm device*, scan only after proper device
addition (ADD event) and not with any other changes (CHANGE event)

 --> if the *PV is a dm device*, scan only after proper mapping
activation (CHANGE event + the underlying PV in a state "just
activated")

RAID:  Limit replacement of devices when array is not in-sync.

If a RAID array is not in-sync, replacing devices should not be allowed
as a general rule.  This is because the contents used to populate the
incoming device may be undefined because the devices being read where
not in-sync.  The kernel enforces this rule unless overridden by not
allowing the creation of an array that is not in-sync and includes a
devices that needs to be rebuilt.

Since we cannot know the sync state of an LV if it is inactive, we must
also enforce the rule that an array must be active to replace devices.

That leaves us with the following conditions:
1) never allow replacement or repair of devices if the LV is in-active
2) never allow replacement if the LV is not in-sync
3) allow repair if the LV is not in-sync, but warn that contents may
   not be recoverable.

In the case where a user is performing the repair on the command line via
'lvconvert --repair', the warning is printed before the user is prompted
if they would like to replace the device(s).  If the repair is automated
(i.e. via dmeventd and policy is "allocate"), then the device is replaced
if possible and the warning is printed.

WHATS_NEW: changelog for fae1a611d2 and 5294a6f77a

lvm2app: No special behavior for 0 for max_snap_size in lvm_lv_snapshot()

It isn't possible to choose a sane default for snapshot size, so just
play it straight and use the passed size instead of adding special
behavior for 0.

Also revert change to Python lib, size parameter must be supplied.

Signed-off-by: Andy Grover <agrover@redhat.com>

Revert "lvmetad: simplify pvid memory allocation."

This reverts commit ed23da95b63308e11f8d680b189686a5d2d380d0.

Hash table device_to_pvid  seems to contain references to
already deleted pvids and so revert to the older
behaviour using allocated memory.

lvmetad: Fix a possible race in remove_metadata.

All operations on shared hash tables need to be protected by mutexes. Moreover,
lookup and subsequent key removal need to happen atomically, to avoid races (and
possible double free-ing) between multiple threads trying to manipulate the same
VG.

lvmetad: Fix a possible deadlock.

If an update and a query were running in parallel, there was a slim but non-zero
chance of a deadlock due to (unnecessary) mutex nesting.

lvmetad: simplify pvid memory allocation.

Since pvid_dup and cft config appears to be tightly
binded together - reuse it's memory pool for string.
Simplifies release of hashes.

thin: dmeventd fix memleak on error path

Some error paths on _umount have leaked bitset.

pv_read: add missing check for valid info

If the lvmcache_info_from_pvid() fails to find valid
info, invoke the lookup by dev, and only in this case
call lvmcache_info_from_pvid() again.

Also check for the result of info and return
error directly, so the NULL is not passed
to lvmcache_get_label().

lvmetad: add check for failure dm_config_write_node

Detect if dm_config_write_node failed and fail correctly.

lvmetad: fix socket leak in handle_connect

Close socket_fd and report error on malloc failure.

lvmetad: check id_read_format error status

Detect error from id_read_format() function.

lvmetad: fix memleak on pv_found error path

Free resources allocated in pv_found when going out
through error path.

lvmetad: keep returned struct fully initialized

Always clear the response structure.
Simplify daemon_reply initialization.

lvmetad: unlock vg on out-of-memory path

If we fail to get memory for mutex, hash the mutex
or fail somewhere along pthread function calls
return allocated resources back and unlock vg_lock_map mutex.

libdaemon: check for strdup result

Detect failure of dm_pool_strdup() and print error in fail path.
Save one extra strchr call - since we already know the distance
for the '=' character.

Drop stack trace from return after log_error().

format-text: check for _text_create_text_instance

Test if 'fid' creation failed and report stack trace,
break the loop and do not pass NULL fid further.

log: move abort past syslog

When the abort_on_internal_errors is enabled, we aborted prior
the syslog logging output.

Since such fatal error gets level _LOG_FATAL it should
not be blocked by debug_level() check so lets move it further,
to get abort error logged also via syslog.

cleanup: use proper const in apply_lvname_restrictions

Better constness used for reserved prefixes and strings.
Also simplify a bit validate_name and use direct char
checks isntead of 2 strcmp() calls.

cleanup: reorder code

Swap if() test condition and check for failure
and use traditional 'stack' trace.

cleanup: skip assignment

env is reassigned without the use, so drop this assign.

cleanup: simplify option matching function

Avoid using sprintf and strncmp call, when
we really want to compare just one character.

cleanup: singlenode minor change

Use strcpy instead of sprintf for plain string.
And use dm_strncpy for safer strncpy.

TODO: Fix API return values for cluster functions.

cleanup: ignore return values

These dm_snprintfs should not fail, since enough space is reserved.
So return intentionaly ignored.

cleanup: ignore errors

Since we are doing just dump and function doesn't report
any error, explicitely ignore return values from
dm_config_write_node and dm_asprintf.

Same applies for the logging function.

cleanup: drop unused header

This header does not resolve any symbols here.

cleanup: drop test for optarg NULL

Since -d takes an argument, we do not need to check for
optarg being NULL here.

cleanup: convert to 32bit

Chunk sizes fits into 4G range, so keep it in 32bit range.

python-lvm: Make second lv.snapshot() argument optional

If no size is given, size defaults to 0, which in lvm_lv_snapshot will
allocate extents equal to the original LV be allocated for the new
snapshot.

Signed-off-by: Andy Grover <agrover@redhat.com>

python-lvm: whitespace in python/liblvm.c.

Sorry, it bugged me. Should be perfect now.

Signed-off-by: Andy Grover <agrover@redhat.com>

python-lvm: Small fixups to new create_lv_snapshot

Tabify

Remove use of asize, unneeded.

Don't initialize lvobj->parent_vgobj to NULL, the object ctor already
zeroed everything on alloc.

Redo call to lvm_lv_snapshot to use the liblvm snapshot implementation
we went with.

Add {}s to silence warning in lv_dealloc.

Rename snapshot function for consistency.

Update WHATS_NEW.

Signed-off-by: Andy Grover <agrover@redhat.com>

python-lvm: Add snapshot support

Signed-off-by: Andy Grover <agrover@redhat.com>

lvm2app: Add lv snapshot support

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

lvconvert: also allow --type with --stripes

We can also use this for conversion between different mirror segment
types. Each new segment type converter then needs to check itself
whether the --stripes is applicable.

Update WHATS_NEW.

toollib: Avoid a global lock in process_each_pv if lvmetad is used.

The motivation to grab the global lock is to avoid a scan and metadata parsing
for each PV, but the cost of obtaining metadata is _mostly_ mitigated by having
lvmetad around. Not taking the global lock improves throughput when multiple pvs
or related commands are running in parallel, like in RHEV.

lvmetad: fix compiler warning and add WHATS_NEW line for previous commit

lvmetad: Fix autoactivation for MDA-less PVs.

Calling pvscan --cache with -aay on a PV without an MDA would spuriously fail
with an internal error, because of an incorrect assumption that a parsed VG
structure was always available. This is not true and the autoactivation handler
needs to call vg_read to obtain metadata in cases where the PV had no MDAs to
parse. Therefore, we pass vgid into the handler instead of the (possibly NULL)
VG coming from the PV's MDA.

lvconvert: allow lvconvert --stripes/stripesize only with -mirrors/--repair/--thinpool

Also, update lvconvert man page to reflect this and make clear that
the --stripes/stripesize is applied to newly allocated space only.

test: update thin discards testing

Reflect fixed disards behavior.

lvmetad: use dm_config_destroy to free pvmeta

Release pvmeta handler with proper dm_config_destroy() function.
TODO: Fix primary fault for this internal error.

Signed-off-by: mcsontos@redhat.com

thin: fix test for dicards ignore settings

Arghh, this was bad last-minute shortening of if() expression
in the commit 1ef98310187a7.

dm_tree_node_set_thin_pool_discard() must not run in the same
expression as check for non-power-2 discard, otherwise
there are 2 calls for dm_tree_node_set_thin_pool_discard
and whole setting of discards is missinterpretted.

In-relase fix it by using proper parentheses {}.

thin: remove detection for thin discard support

Remove no longer needed warning for unsuppoted discards
for non-power-2 lvcreate commands.

(Missed from the patch for the same update in lvchange made
by commit dde5a6c52b315d7b)

mirrors: fix leak in device_is_usable mirror check

Function _ignore_blocked_mirror_devices was not release
allocated strings images_health and log_health.

In error paths it was also not releasing dm_task structure.

Swaped return code of _ignore_blocked_mirror_devices and
use 1 as success.

In _parse_mirror_status use log_error if memory allocation
fails and few more errors so they are no going unnoticed
as debug messages.

On error path always clear return values and free strings.

For dev_create_file  use cache mem pool to avoid memleak.

lvconvert: do not ignore -f in lvconvert --repair -y -f

Fix Py_BuildValue for i386

see https://bugzilla.redhat.com/show_bug.cgi?id=881989

Signed-off-by: James Antill <james.antill@redhat.com>
Signed-off-by: Andy Grover <agrover@redhat.com>

pvmove/RAID:  Disallow pvmove on RAID LVs until properly handled

Attempting pvmove on RAID LVs replaces the kernel RAID target with
a temporary pvmove target, ultimately destroying the RAID LV.  pvmove
must be prevented on RAID LVs for now.

Use 'lvconvert --replace old_pv vg/lv new_pv' if you want to move
an image of the RAID LV.

activation: don't miss the log on empty {auto_activation|read_only|}_volume_list

Addendum to previous commit...

Allow empty activation/{auto_activation|read_only|}_volume_list config option.

In case we don't want to activate, autoactivate or have the
VG/LV read-only. Primarily targeted for the auto_activation_volume_list,
but it makes no harm for other settings (the part of the code
that reads these three settings is shared, but there's no
reason to separate it only for this change).

thin: update thin feature detection

Safe 1 static var and keep whole detection within one function.

thin: reworked thin feature detection

Rework thin feature detection to support runtime
section to allow to disable them selectively.

New lvm.conf option is born: global/thin_disabled_features

thin: lvconvert supports swapping metadata device

Support swapping of metadata device if the thin pool already
exists. This way it's easy to i.e. resize metadata or their
repair operation.

User may create some empty LV, replace existing metadata
or dump and restore them into bigger LV.

libdm: deactivate failed node in preload

If the resume of preloaded node fails, do not leave such
node in the table - since it may not be easy to detach such
node later when the node is i.e. internal.

i.e. failing activation of the thin pool with mismatching
chunk size may leave -tpool device in the table, which
could have been then removed only by dmsetup command.

thin: deactivate subvolumes

Do not leave active thin data and metadata volumes
if activation of thin pool fails.

thin: lvchange may change discards freely

thin: shuffle code

Reorder code lines for next patch.

thin: lvconvert update messages

thin: add detach_pool_metadata_lv

Add internal function detach_pool_metadata_lv().

tests: add error_dev aux

Aux function to replace PV with specifically damaged device.
Usage:

   aux error_dev "$dev1" 8:32 96:8

Replaces from 8 sector 32 error 512b sectors
and from 96 sector next 8 sectors will fail on rw.
Rest of device is preserved.

For testing:
dd if="$dev1" of=x bs=512 count=104 conv=sync,noerror iflag=direct

tests: resume devices on background

Since some devices may need correct order of their resuming,
resume then all on background and wait for finish.

lvm2api: fix size reporting

API is reporting all sizes as 64bit integers in bytes.
Fix at those places, where sectors were returned
to remain consistent.

man page (lvcreate):  Better explain stripes option for RAID 4/5/6.

Do a better job explaining the '--stripes/-i' option to lvcreate
when it comes to RAID 4/5/6.  The extra devices needed for parity
are implicitly added to the argument given.  So a 5-device RAID6
logical volume is created with '-i 3' - indicating 3 stripes plus
the implicit 2 devices needed for RAID6.

udev: add a warning message if DM_DISABLE_UDEV set and udev running

$ export DM_DISABLE_UDEV=1

$ dmsetup create test --table "0 1 zero"
Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, device-mapper library will manage device nodes in device directory.

$ lvchange -ay vg/lvol0
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will manage logical volume symlinks in device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will obtain device list by scanning device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, device-mapper library will manage device nodes in device directory.

udev: _udev_disabled var visible also for !UDEV_SYNC_SUPPORT

udev: recognize DM_DISABLE_UDEV environment variable

Setting this environment variable will cause a full fallback
to old direct node and symlink management in libdevmapper and lvm2.

It means:

 - disabling udev synchronization
   (--noudevsync in dmsetup and --noudevsync + activation/udev_sync=0
    lvm2 config)
 - disabling dm and any subsystem related udev rules
   (--noudevrules in dmsetup and activation/udev_rules=0 lvm2 config)
 - management of nodes/symlinks under /dev directly by libdevmapper/lvm2
   (--verifyudev in dmsetup and activation/verify_udev_operations=1
    lvm2 config)
 - not obtaining any device list from udev database
   (devices/obtain_device_list_from_udev=0 lvm2 config)

Note: we could set all of these before - there's no functional change!
However the DM_DISABLE_UDEV environment variable is a nice shortcut
to make it easier for libdevmapper users so that one can switch off all
of the udev management off at one go directly on the command line,
without a need to modify any source or add any extra switches.

udev: do not verify udev operations for --noudevsync

If udev synchronization is disabled by means of --noudevsync
option, we should disable just the synchronization and nothing else.
The udev fallback (verifying udev operations and fixing the
nodes/symlinks if found incorrect) is orthogonal and controlled
by a separate activation/verify_udev_operations configuration option.

tests: update thin testing

thin: fix property discard for lvm2api

Discards property is string and may have these values:
  ignore, nopassdown, passdown

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.

thin: fix attrs for unloaded driver

If the driver is not loaded, set all 'features' ON
instead of all of them being OFF.

filters: Add STEC skd and Violin vtms devices

thin: support configurable thin pool defaults

Configurable settings for thin pool create
if they are not specified on command line.

New supported lvm.conf options are:
  allocation/thin_pool_chunk_size
  allocation/thin_pool_discards
  allocation/thin_pool_zero

thin: add more unsupporte options for merge

Hmm, we need some smarter way to detect unsupported command
line options for various commands.