raid: drop debug code

raid: more origin_only updates

Seems the code is multiplied - so keep it consistent for now.

TODO:  drop all uneeded code

lvconvert: provide better reshape reject message for open RaidLV

On commits
5e611c700ba1032ffb71bf0cdd33e062e5e16439 and
601ad1c73faa5fe3d74ff5b06cc47073b40a1850.

Related: rhbz1447812

raid: avoid explicit activation of SubLVs on reshape/takeover

Remove explicit activation of SubLVs and let lv_update_and_reload()
perform the proper (pre-)loading sequencing of tables.
This avoids related callback functions which are removed.

Related: rhbz1448116
Related: rhbz1461526
Related: rhbz1448123

raid: provide clickable URL BZ references

tests: test also different lock holder

tests: avoid double lines

Skip showing same line twice in test's verbose log.

activation: fix usage of origin_only

When lock-holding LV differs from actually request locked LV,
we drop  origin_only flag as it has no use - it'd be applied
on completely different LV.

Example of problem:

Raid is  thin-pool _tdata LV.
Raid run  origin_only locking on stacked device.
As lock holder is discovered thinLV.
Whole origin_only operation is then applied only on thinLV
changing the meaning of whole operation.

NOTE: this patch does not change anything for LV that are
already top-level lock holding LVs (i.e. thinLVs, snahoshots/origins).

lvconvert: check open count to disable reshaping of open RAID LV

Also check LV open count in addition to opening the RaidLV
exclusively as of commit 601ad1c73faa5fe3d74ff5b06cc47073b40a1850.

Related: rhbz1447812

lvconvert: enhance disable reshaping of open RAID LV

Enhance commit 9e9163618ab36a6b046b6380d6ef58429b219ef8
to use dev_open_flags/dev_close API.

Related: rhbz1447812

tests: check conversion of thin-pool

thin: restore conversion to raid

Since commit  1bc546269a7d2cae156827e282715410a4967d51 we've disabled
coversion of raid. This however already got fixed, so reenable
commands like:  'lvconvert --type raid1 vg/pool_tdata'.

lvconvert: disable reshaping of open RAID LV

Disable until we have a proper fix for reshape space allocation,
switching it to begin/end of rimages and activation.

Related: rhbz1447812

lvconvert: enhance message

Enhance message introduced by last
commit f342e803ba3c32890a2b08736fa94bdd541d5e9c.

Related: rhbz1439399

lvconvert: disable conversion of RAID LV under snapshot

Disable until we have a proper fix for reshape space allocation,
switching it to begin/end of rimages and activation.

Related: rhbz1439399

lvconvert: disable reshaping of RAID LVs in the cluster

Disable until we have a proper fix for reshape space allocation,
switching it to begin/end of rimages and activation in the cluster.

Related: rhbz1448116
Related: rhbz1461526
Related: rhbz1448123

fsadm: restore no answer

Commit 1fe4f80e45a6bfcceed5aaab97fc0e27dfcf2b88 in current version
introduced regression for a terminal user, as he could not enter 'n'
as answer. Add missing break for this case (No whats_new).

test: New test file for validating kernel status during sync ops

New tests to add checking for '100%' in-sync at start of "recover"
process (it shouldn't happen, but I've seen it before).  Also,
check status over the whole cycle of various sync processes ("resync"
and "recover").

tests: use exclusive activation

Conversion needs exlusively active LV for clustered testing.

debug: passing non-raid seg would be internal error

cleanup: drop unused parameter

cleanup: show what happens when passed prompt

When we show prompt and user passes --yes - we still
do tell user which action is going to happen.

cleanup: improve debug tracing

cleanup: use 'dm_get_status_raid'

Use single 'dm' call to parse raid status.
(Avoiding multiple parsers - even when we know it's slighly
less efficient).

raid: report percent with segtype info

Enhance reporting code, so it does not need to do 'extra' ioctl to
get 'status' of normal raid and provide percentage directly.

When we have 'merging' snapshot into raid origin, we still need to get
this secondary number with extra status call - however, since  'raid'
is always a single segment LV - we may skip 'copy_percent' call as
we directly know the percent and also with better precision.

NOTE: for mirror we still base reported number on the percetage of
transferred extents which might get quite imprecisse if big size
of extent is used while volume itself is smaller as reporting jump
steps are much bigger the actual reported number provides.

2nd.NOTE: raid lvs line report already requires quite a few extra status
calls for the same device - but fix will be need slight code improval.

libdm: workarounds reported raid status info

Current existing kernels reports status sometimes in weird form.

Instead of showing what is the exact progress, we need to estimate
this in-sync state from several surrounding states.

Main reason here is to never report 100% sync state for a raid device
which will be undergoing i.e. recovery.

raid: adjust reshape feature flag check

Relative to last comit ddf2a1d6564800f6d7f87e91cb8a7dfaa0edac1f:

adjust the dm-raid target version to 1.12.0 which shows
mandatory kernel MD deadlock fixes related to reshaping
are presant in the kernel.

Related: rhbz1443999

Revert "lvconvert: reject changing number of stripes on single core

This reverts commit 3719f4bc5441cb5f29ad4beb91ccaa6b234ea8e1
to allow for single core testing on kernels with deadlock
fixes relative to rhbz1443999."

test: New test file for validating kernel status during sync ops

First test in this file checks whether 'aa' is ever spotted during
a "recover" operation (it should not be).  More tests should follow
in this file to look for oddities in status output - especially as
it relates to the sync_ratio, dev_health, and sync_action fields.

clean-up:  Very picky update to comment - hopefully making it clearer

clean-ups:  remove unused var, add 'static' for local fn, adjust test

For the test clean-up, I was providing too many devices to the first
command - possibly allowing it to allocate in the wrong place.  I was
also not providing a device for the second command - virtually ensuring
the test was not performing correctly at times.

lvconvert: Disallow removal of primary when up-converting (recovering)

This patch ensures that under normal conditions (i.e. not during repair
operations) that users are prevented from removing devices that would
cause data loss.

When a RAID1 is undergoing its initial sync, it is ok to remove all but
one of the images because they have all existed since creation and
contain all the data written since the array was created.  OTOH, if the
RAID1 was created as a result of an up-convert from linear, it is very
important not to let the user remove the primary image (the source of
all the data).  They should be allowed to remove any devices they want
and as many as they want as long as one original (primary) device is left
during a "recover" (aka up-convert).

This fixes bug 1461187 and includes the necessary regression tests.

RAID (lvconvert/dmeventd):  Cleanly handle primary failure during 'recover' op

Add the checks necessary to distiguish the state of a RAID when the primary
source for syncing fails during the "recover" process.

It has been possible to hit this condition before (like when converting from
2-way RAID1 to 3-way and having the first two devices die during the "recover"
process).  However, this condition is now more likely since we treat linear ->
RAID1 conversions as "recover" now - so it is especially important we cleanly
handle this condition.

lvconvert:  Don't require a 'force' option during RAID repair.

Previously, we were treating non-RAID to RAID up-converts as a "resync"
operation.  (The most common example being 'linear -> RAID1'.)  RAID to
RAID up-converts or rebuilds of specific RAID images are properly treated
as a "recover" operation.

Since we were treating some up-convert operations as "resync", it was
possible to have scenarios where data corruption or data loss were
possibilities if the RAID hadn't been able to sync completely before a
loss of the primary source devices.  In order to ensure that the user took
the proper precautions in such scenarios, we required a '--force' option
to be present.  Unfortuneately, the force option was rendered useless
because there was no way to distiguish the failure state of a potentially
destructive repair from a nominal one - making the '--force' option a
requirement for any RAID1 repair!

We now treat non-RAID to RAID up-converts properly as "recover" operations.
This eliminates the scenarios that can potentially cause data loss or
data corruption; and this eliminates the need for the '--force' requirement.
This patch removes the requirement to specify '--force' for RAID repairs.

lvconvert:  linear -> raid1 upconvert should cause "recover" not "resync"

Two of the sync actions performed by the kernel (aka MD runtime) are
"resync" and "recover".  The "resync" refers to when an entirely new array
is going through the process of initializing (or resynchronizing after an
unexpected shutdown).  The "recover" is the process of initializing a new
member device to the array.  So, a brand new array with all new devices
will undergo "resync".  An array with replaced or added sub-LVs will undergo
"recover".

These two states are treated very differently when failures happen.  If any
device is lost or replaced while "resync", there are no worries.  This is
because any writes created from the inception of the array have occurred to
all the devices and can be safely recovered.  Even though non-initialized
portions will still be resync'ed with uninitialized data, it is ok.  However,
if a pre-existing device is lost (aka, the original linear device in a
linear -> raid1 convert) during a "recover", data loss can be the result.
Thus, writes are errored by the kernel and recovery is halted.  The failed
device must be restored or removed.  This is the correct behavior.

Unfortunately, we were treating an up-convert from linear as a "resync"
when we should have been treating it as a "recover".  This patch
removes the special case for linear upconvert.  It allows each new image
sub-LV to be marked with a rebuild flag and treats the array as 'in-sync'.
This has the correct effect of causing the upconvert to be treated as a
"recover" rather than a "resync".  There is no need to flag these two states
differently in LVM metadata, because they are already considered differently
by the kernel RAID metadata.  (Any activation/deactivation will properly
resume the "recover" process and not a "resync" process.)

We make this behavior change based on the presense of dm-raid target
version 1.9.0+.

raid: change reshape segtype flags

Commit 1c916ec5ffd37cfb7be2101b93a2dc91aa2ef7f0
missed new reshape flags.

lvconvert: fix detached SubLV deactivation in cluster

On conversion from raid10 to raid0 (takeover), all rmeta
devices and the rimage devices of mirrored stripes are
detached from the raid10 LV. The remaining rimage areas
are being shifted down into the slots of the detached
ones hence requiring renames to show proper _N suffix
sequences (e.g. 0,1,2,3 instead of 0,2,4,6).  Only the
top-level raid10 LV has a cluster lock, not the detached
SubLVs thus their deactivation is impossible and e.g the
rename from *_rimage_6 to *_rimage_3 will fail.  Fix by
activating exclusively before deactivating and removing.

Resolves: rhbz1448123

dmfilemapd: do not wait if file has been truncated

dmfilemapd: update file block count at daemon start

The file block count stored in the filemap_monitor was lazily
initialised at the time of the first check. This causes problems
in the case that the file has been truncated between this time and
the time the daemon started: the initial block count and current
block count match and the daemon fails to detect a change.

Separate the setting of the block count from the check and make a
call to update the value at the start of _dmfilemapd().

libdm: allow truncated files in dm_stats_update_regions_from_fd()

It's not an error to attempt to update regions from an fd that has
been truncated (or otherwise no longer has any allocated extents):
in this case, the call should remove all regions corresponding to
the group, and return an empty region table.

configure: update

configure: search for (a possibly prefixed) ar

e.g. when cross compiling.

Signed-off-by: Heiko Becker <heirecka@exherbo.org>

configure: improve reporting about readline

Report real 'readline' supporting state instead of 'maybe'.
Really check for 'readline' headers.

configure: warn about older version of cache_check

For proper usage of Cache kernel metadata format V2,
new cache_check tool is basically mandatory.

Print warning during configure time about this problem.

raid: add reshape segtype flag support

Prohibit activation of reshaping RaidLVs on incompatible
lvm2 runtime by storing e.g. 'raid5+RESHAPE' segment type
strings in the lvm2 metadata.  Incompatible runtime not
supporting reshaping won't be able to activate those thus
avoiding potential data corruption.

Any new non-reshaping lvconvert command will reset the
segment type string from 'raid5+RESHAPE' to 'raid5'.

See commits
0299a7af1ec1eeb11388ed15c4c78f224fee76b2 and
4141409eb09e78aef030346995f1722fb40956d8
for segtype flag support.

indent: properly indent goto

cleanup: update message

cleanup: define really uses KB

Cleanup also units for DEFAULT_THIN_POOL_OPTIMAL_METADATA_SIZE define
(128MB) and update calcs for it.

snapshot: fix reporting for merged old snapshot

When old snapshot is merged, lvm2 still can report some data about
merged 'snapshot' - i.e. it occupied space in VG.

This patch fixes regression from commit:
6fd20be629b6dceb96702c5f875a2e612e6f465d

and resolved RHBZ: 1460161

tests: no longer allowed too big thin-pools for small chunks

configure: report yes or no for wiping and system

Avoid reporting 'checking result' as maybe - it should
clearly tell 'yes' or 'no'.

Just shuffle printed message to the place, where we
already know the 'maybe' answer.

So instead of printing 'unclear':

checking whether to enable libblkid detection of signatures when wiping... maybe
checking for BLKID... yes
checking whether to use udev-systemd protocol for jobs in background... maybe
checking for SYSTEMD... yes

show this:

checking for BLKID... yes
checking whether to enable libblkid detection of signatures when wiping... yes
checking for SYSTEMD... yes
checking whether to use udev-systemd protocol for jobs in background... yes

cache: lvcreate --cachepool checks for cache pool

Code path missed validation of lvcreate --cachepool argument.
If the non cache-pool LV was passed in, code has still continued
further work and failed later on internal error.  Validate this
condition at right place now.

tests: fix compilation of unit tests

Rule for TARGET compiling got missing and needs to be explicitely
expressed, otherwise default unsuitable rule is applied.

tests: check thin-pool boundary sizes

thin: disallow creation of too big thin pools

When a combination of thin-pool chunk size and thin-pool data size
goes beyond addressable limit, such volume creation is directly
prohibited.

Maximum usable thin-pool size is calculated with use of maximal support
metadata size (even when it's created smaller) and given chunk-size.
If the value data size is found to be too big, the command reports
error and operation fails.

Previously thin-pool was created however lots of thin-pool data LV was
not usable and this space in VG has been wasted.

cleanup: use DM limit define

For calculation use already defined size in libdm, which give better
estimation of maximal size of thin pool metadata.

cleanup: rename internal define

More descriptive name of #define.

lvconvert: reject RAID conversions on inactive LVs

Only support RAID conversions on active LVs.

If we'd accept e.g. upconverting linear -> raid1 on inactive
linear LVs, any LV flags passed to the kernel aren't properly
cleared thus errouneously passing them on every activation.

Add respective check to lv_raid_change_image_count() and
move existing one in lv_raid_convert() for better messages.

lvmdbusd: Prevent stall when update thread gets exception

If during the process of fetching current lvm state we experience an
exception we fail to call set_result on the queued_requests we were
processing.  When this happens those threads block forever which causes
the service to stall infinitely.  Only clear the queued_requests after
we have called set_result.

lvmdbusd: Add background command to flight recorder

We were not adding background tasks to flight recorder.  Add the meta
data to the flight recorder when we start the command and update the meta
data when the command is finished.  Locking was added to meta data to
prevent concurrent update and returning string representation as these can
happen in two different threads.

lvmdbusd: cmdhandler.py vg_reduce, remove extranous '--all'

vgreduce previously allowed --all and --removemissing together even though
it only actual did the remove missing.  The lvm dbus daemon was passing
--all anytime there was no entries in pv_object_paths.  This change supplies
--all if and only if we are not removing missing and the pv_object_paths
is empty.

Vgreduce has and continues to enforce the invalid combination of supplying a
device list when you specify --all or --removemissing so we do not need
to check for that invalid combination explicitly in the lvm dbus service as
it's already covered.

Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1455471

lvconvert: choose direct path to desired raid level

Remove superfluous raid5_n interim LV type from raid4 -> raid10 conversion.

Resolves: rhbz1458006

print warning about in-use orphans

Warn about a PV that has the in-use flag set, but appears in
the orphan VG (no VG was found referencing it.)

There are a number of conditions that could lead to this:

. The PV was created with no mdas and is used in a VG with
  other PVs (with metadata) that have not yet appeared on
  the system.  So, no VG metadata is found by lvm which
  references the in-use PV with no mdas.

. vgremove could have failed after clearing mdas but
  before clearing the in-use flag.  In this case, the
  in-use flag needs to be manually cleared on the PV.

. The PV may have damanged/unrecognized VG metadata
  that lvm could not read.

. The PV may have no mdas, and the PVs with the metadata
  may have damaged/unrecognized metadata.

disable repairing in-use flag on orphan PVs

A PV holding VG metadata that lvm can't understand
(e.g. damaged, checksum error, unrecognized flag)
will appear as an in-use orphan, and will be cleared
by this repair code.  Disable this repair until the
code can keep track of these problematic PVs, and
distinguish them from actual in-use orphans.

tests: longer delay

Slower sync a bit more and use bigger raid arrays to
be more sure we will catch raid being sychronized.

tests: add some extra udev waits

To get less random results on older systems with systemd (i.e. fc23)
put few extra udev wait operations to avoid any udev event collision.

tests: skip reshaping raid10

Needs newer target  >= 1.10.1 for reshaping of raid10 LVs.

lvconvert: reject changing number of stripes on single core

Reject any stripe adding/removing reshape on raid4/5/6/10 because
of related MD kernel deadlock on single core systems until
we get a proper fix in MD.

Related: rhbz1443999

tests: missed to export lvm binary for fsadm

tests: drop extra debug vvvv

Also show output of mount so when it fails we can check the state.

tests: also check new flag with segtype

Make sure new unknown flag is having same behavior as old unknown segtype.

flags: improve unknown flags logic

Use same logic as with unknown segment type - so preserve such
name fully with all flags just with UNKNOWN segment type bits.

flags: restore same logic with MISSING

Since lvmetad is using 'MISSING' in status for 'another' purpose,
we need to support ATM also flag get from this place.

Until fixed better - we accept both flags - alhough lvm2 will
only print in flags.

flags: add segtype flag support

Switch METADATA_FORMAT flag usage to be stored via segtype
instead of 'status' flag which appeared to cause major
incompatibility troubles.

For backward compatiblity segtype flags are still accepted also
via 'status' bits which were used from version 2.02.169 so metadata
saved by this newer lvm2 version should still work nicely, although
new save version will no longer work on this older lvm2 version.

flags: add read and print of segtype flag

Allow storing LV status bits with segment type name field.
Switching to this since this field has better support for compatibility
with older version of lvm2 - since such unknown segtype will not cause
complete invisiblity of metadata from older lvm2 code - just the
particular LV will become unusable with unknown type of segment.

cleanup: backtrace

Add debug backtrace.

cleanup: separate type and mask

Split misused 'enum' into 2 fields - one for type
of PV, VG, LV and other for mask.

cleanup: bad flag is internal error here

Convert to internal error.

tests: wait for raid in sync

Lvchange needs synchronized raid.

test: Fix dbus testing using testsuite

- Must reread all objects as PVs might be removed.
- Never consider testsuite provided PVs nested, or tearDown fails to
  remove any outstanding VGs on them.

test: Use _pv suffix for nested devices

Testsuite uses global_filter to accept only test devices with
suffix matching /_pv[0-9_]*$/ set by generate_config in aux.sh.

spec: Enable notify-dbus in builds with dbus

Proper dm_snprintf return checks

Fix typo

add comment about PV in-use repair

copied from commit message for
d97f1c89deb9a75452059cd62ebb20cf7d2d6bfa

man lvmsystemid: change some wording

Clarify the wording in a couple cases.

tests: fix test for fsadm

Avoid mountinfo
Pass 'y'  - since ATM lvresize cannot pass --yes to fsadm.

fsadm: avoid hidden --yes

When 'fsadm' was running without terminal (i.e. pipe), it's been
automatically working like in '--yes'.

Detect terminal and only accept empty "" input in this mode.

raid: Drop unnecessary/incorrect use of dm_pool_free

metadata: Unlock VG on more _vg_make_handle error paths

Internal error: VG lock vg0 must be requested before vg3, not after.
Internal error: 3 device(s) were left open and have been closed.

format_text: More internal errors if given invalid internal metadata

Three more messages to ensure each failure in out_areas() results in a
low-level message instead of sometimes just <backtrace>.

man lvmraid: add more indirect conversion info

tests: catch some fsadm tricky paths

When user is renaming a device, we are getting into troubles.
We needs to recognize which case is actually supportable by fsadm.

fsadm: enhance detection of already mounted volumes

Add more validation to catch mainly renamed devices, where
filesystem utils are not able to handle devices properly,
as they are not addressed by major:minor by rather via some
symbolic path names which can change over time via rename operation.

fsadm: always detect mounted fs with extX

Since we add more validation to 'detect_mounted' function make sure
we always use it even with 'resize' action, so numerous validations
are not skipped.

man lvmraid: indirect conversions

Start documenting multi-step conversions.

Don't number examples.

lvconvert: fix logic in automatic settings of possible (raid) LV types

Commit 5fe07d3574ddce3d194f0fa57af9028348a91008 failed to set raid5 types
properly on conversions from raid6.  It always enforced raid6_ls_6
for types raid6/raid6_zr/raid6_nr/raid6_nc, thus requiring 3 conversions
instead of 2 when asking for raid5_{la,rs,ra,n}.

Related: rhbz1439403

lvmdbusd: Fix missed rename

Introduced By: e53454d6 (2.02.169)
Related: RHBZ#1348688

lvconvert: fix indent and typo in last commit

lvconvert: enhance automatic settings of possible (raid) LV types

Offer possible interim LV types and display their aliases
(e.g. raid5 and raid5_ls) for all conversions between
striped and any raid LVs in case user requests a type
not suitable to direct conversion.

E.g. running "lvconvert --type raid5 LV" on a striped
LV will replace raid5 aka raid5_ls (rotating parity)
with raid5_n (dedicated parity on last image).
User is asked to repeat the lvconvert command to get to the
requested LV type (raid5 aka raid5_ls in this example)
when such replacement occurs.

Resolves: rhbz1439403