pvscan: print more reasons for ignoring devices

tests: update pvscan-autoactivate for init change

pvscan: don't print warning about lvmlockd not running

pvscan --cache ignores shared VGs, so it doesn't need to
consider lvmlockd, and shouldn't include a warning about it.

pvscan: remove initialization case

In the past, the first 'pvscan --cache -aay dev' command
to run on the system would initialize the pvs_online dir
by scanning all devs and creating online files for all pvs
it found, and then autoactivating the VG (if complete) for
the named dev.  The idea was that the system may not have
been able to run pvscan commands for early devices, so the
first pvscan to run would need to "make up" for any devices
that had appeared previously, which the system was unable to
scan.  The problem or idea of making up for missed scans is
historical and should no longer be needed, so remove this
special init case.

pvscan: for init only autoactivate vg for named dev

When pvscan is run for the initialization case (the first
pvscan run on the system), it scans all devs and creates
online files for all PVs it finds.  Previously it would
then autoactivate every complete VG, but change this to
only autoactive the (complete) VG corresponding to the
named device arg(s).

pvscan: reorganize code

to simplify and prepare for subsequent change.
Should be no change in behavior.

man: updates to lvmlockd

- remove reference to locking_type which is no longer used
- remove references to adopting locks which has been disabled
- move some sanlock-specific info out of a general section
- remove info about doing automatic lockstart by the system
  since this was never used (the resource agent does it)
- replace info about lvextend and manual refresh under gfs2
  with a description about the automatic remote refresh

lvmlockd: do not allow mirror LV to be activated shared

This reverts 518a8e8cfbb672c2bf5e3455f1fe7cd8d94eb5b0
  "lvmlockd: activate mirror LVs in shared mode with cmirrord"

because while activating a mirror LV with cmirrord worked,
changes to the active cmirror did not work.

lvextend: refresh shared LV without using select

Using select instead of normal args did not end
up being a help, so remove it.

tests: check auto-growth of thin-pool meta

thin: fix maintenance of _pmspare

When metadata grows lvm2 may need to extend also _pmspare volume.

thin: resize metadata with data

When data are growing, adapt also size of metadata.
As we get way too many reports from users doing huge growths of
data portion while keep metadata small and avoiding using monitoring.

So to enhance the user-experience in case user requests grown of
thin-pool (without passing PV list for growth) - lvm2 will automaticaly
grown also the metadata part of thin-pool (if possible).

thin: introduce estimate_thin_pool_metadata_size

Add function for estimation of thin-pool metadata size for given size of
data. Function is using already existing internal API so it can
be reused for resize of thin-pool data.

filter: fix mpath test

Fix bug which leaked into commit
dc6dea40331687b8740cc48833f4c7c42a2db1a1,
where the testing code got mistakenly commited.

lvresize: fix when compiled without lvmlockd

The no-op result of lockd_lv_resize should be success.

lvextend: refresh shared LV with vgname as arg

Update the previous commit to leave the vgname as
an arg instead of moving it into the select option,
(the compound select option rule is confusing the
dlm arg processing.)

lvextend: refresh shared LV using select option

Using --select 'lvname=LV && vgname=VG' avoids the problem
of the lvchange exit code not distinguishing an actual error
result vs the VG or LV not existing.  (This is in case there
is an odd dlm/gfs2 setup where some nodes are running the dlm
but do not have access to the VG.)

lvextend: refresh shared LV remotely using dlm/corosync

When lvextend extends an LV that is active with a shared
lock, use this as a signal that other hosts may also have
the LV active, with gfs2 mounted, and should have the LV
refreshed to reflect the new size.  Use the libdlmcontrol
run api, which uses dlm_controld/corosync to run an
lvchange --refresh command on other cluster nodes.

lvextend: allow on LV active with a shared lock

Detect when a shared lock exists, don't require the
normal exclusive lock, and allow the lvextend.

warn about changes to an active lv with shared lock

When an LV is active with a shared lock, a command can be
run to change the LV with --lockopt skiplv (to override the
exclusive lock the command ordinarily requires which is not
compatible with the outstanding shared lock.)

In this case, other commands may have the LV active and may
need to refresh the LV, so print warning stating this.

tests: vdo caching tests

tests: vdo dmevent autoresize

man: dmeventd vdo plugin

man: basic vdo stacking support

Document some basic lvconvert stacking posibilities.

activation: synchronize before removing devices

Udev is running udev-rule action upon 'resume'.

However lvm2 in special case is doing replacement of
'soon-to-be-removed' device with 'error' target for resuming
and then follows actual removal - the sequence is usually quick,
so when udev start action - it can result in 'strange' error
message in kernel log like:

Process '/usr/sbin/dmsetup info -j 253 -m 17 -c --nameprefixes --noheadings --rows -o name,uuid,suspended' failed with exit code 1.

To avoid this - we need to ensure there is synchronization wait for udev
between 'resume'  and 'remove' part of this process.

However existing code put strict requirement to avoid synchronizing with
udev inside critical section - but this originally came from requirement
to not do anything special while there could be devices in
suspend-state. Now we are able to see differnce between critical section
with or without suspended devices.  For udev synchronization only
suspended devices are prohibited to be there - so slightly relax
condition and allow calling and using 'fs_sync()' even inside critical
section - but there must not be any suspended device.

vdo: enable caching for vdopool LV and vdo LV

Allow using caching with VDO.
User can either cache a single vdopool or
a vdo LV - difference when the caching is put-in depends on a use-case
and it's upto user to decide which kind of speed is expected.

lv_manip: insert remove layer skips pools

Fixing renaming of subLVs when removing and inserting layers - this
got visible when using stacked VDO pools.

tests: check vgsplit works with cache

cache: support vgsplit

Enable vgsplit to work with VG containing cached LVs.

thin: max thin

debug: use log_warn

This reports are not causing command failure, so report them as
warning.

filter: enhance mpath detection

Internal detection of SCSI device being in-use by DM mpath has been
performed several times for each component device - this could be
eventually racy - so instead when we do remember  1st. checked result
for device being mpath and use it consistenly over the filter runtime.

dev_manager: add dev_manager_remove_dm_major_minor

Move DM usage into dev_manager.c source file.
Also convert STATUS to INFO ioctl - as that's enough
to obtain UUID - this also avoid issuing unwanted flush on checked DM
device for being mpath.

gitignore: update

pvscan: fix ignoring foreign PVs

Fix to previous commit
  "pvscan: ignore online for shared and foreign PVs"

which was incorrectly considering a PV foreign if its
VG had no system ID when the host did have a system ID.

config: improve scan_lvs description

tests: check that pvscan --cache ignores certain PVs

pvscan: ignore online for shared and foreign PVs

Activation would not be allowed anyway, but we can
check for these cases early and avoid wasted time in
pvscan managing online files an attempting activation.

pvscan: ignore online for unused PV

If an unused PV comes online, ignore it from
pvscan --cache.

WHATS_NEW: io_memory_size

io: increase the default io memory from 4 to 8 MiB

This is the default bcache size that is created at the
start of the command.  It needs to be large enough to
hold a single copy of metadata for a given VG, or the
VG cannot be read or written (since the entire VG would
not fit into available memory.)

Increasing the default reduces the chances of anyone
needing to increase the default to use their VG.

The size can be set in lvm.conf global/io_memory_size;
the lower limit is 4 MiB and the upper limit is 128 MiB.

io: warn when metadata size approaches io memory size

When a single copy of metadata gets within 1MB of the
current io_memory_size value, begin printing a warning
that the io_memory_size should be increased.

config: add new setting io_memory_size

which defines the amount of memory that lvm will allocate
for bcache.  Increasing this setting is required if it is
smaller than a single copy of VG metadata.

remove unused io functions

logging: remove unused code

Incomplete bits of original code that's unused.

pvscan service: use StartLimitIntervalSec

systemd changed the name

Use "cachevol" to refer to cache on a single LV

and "cachepool" to refer to a cache on a cache pool object.

The problem was that the --cachepool option was being used
to refer to both a cache pool object, and to a standard LV
used for caching.  This could be somewhat confusing, and it
made it less clear when each kind would be used.  By
separating them, it's clear when a cachepool or a cachevol
should be used.

Previously:

- lvm would use the cache pool approach when the user passed
  a cache-pool LV to the --cachepool option.

- lvm would use the cache vol approach when the user passed
  a standard LV in the --cachepool option.

Now:

- lvm will always use the cache pool approach when the user
  uses the --cachepool option.

- lvm will always use the cache vol approach when the user
  uses the --cachevol option.

config: make hints setting commented

logging: new config settings to specify debug fields

For users who do not want all of the fields included
in debug lines, let them specify in lvm.conf which
fields to include.  timestamp, command[pid], and
file:line fields can all be disabled.

pvscan: fix hint recreation

Restore part of the fix from f0089472e7 that was lost
in the process of backporting 74a388cca1.

logging: add command[pid] and timestamp to file and verbose output

Without this, the output from different commands in a single
log file could not be separated.

Change the default "indent" setting to 0 so that the default
debug output does not include variable spaces in the middle
of debug lines.

dmsetup: Fix multi-line concise table parsing

Use the correct loop variable within the loop, instead of reusing the
initial value.  Table lines after the first don't get terminated in
the right place.

Signed-off-by: Kurt Garloff <kurt@garloff.de>

WHATS_NEW: concurrent pvscan autoactivation

pvscan: autoactivate a VG once

When a VG has multiple PVs, and all those PVs come online
at the same time, concurrent pvscans for each PV will all
create the individual pvid files, and all will often see
the VG is now complete.  This causes each of the pvscan
commands to think it should activate the VG, so there
are multiple activations of the same VG.  The vg lock
serializes them, and only the first pvscan actually does
the activation, but there is still a lot of extra overhead
and time used by the other pvscans that attempt to
activate the already active VG.  This can lead to a backlog
of pvscans and timeouts.

To fix this, this adds a new /run/lvm/vgs_online/ dir that
works like the existing /run/lvm/pvs_online/ dir.  Each pvscan
that wants to activate a VG will first try to exlusively create
the file vgs_online/<vgname>.  Only the first pvscan will
succeed, and that one will do the VG activation. The other
pvscans will find the vgname file exists and will not do the
activation step.

When a PV goes offline, the vgs_online file for the corresponding
VG is removed.  This allows the VG to be autoactivated again
when the PV comes online again.  This requires that the vgname be
stored in the pvid files.

pvscan: fix autoactivation from concurrent pvscans

Use a file lock to ensure that only one pvscan will do
initialization of pvs_online, otherwise multiple concurrent
pvscans may all see an empty pvs_online directory and
do initialization.

The pvscan that is doing initialization should also only
attempt to activate complete VGs.

WHATS_NEW: scan_lvs default change

tests: set scan_lvs=1 in tests that stack PVs on LVs

config: change scan_lvs default to 0

so that lvm does not scan LVs for PVs by default.

hints: fix recreating hints from pvscan

When aay was included in the pvscan --cache command,
the activation part was complaining about the unusual
state of the hint file since it had been recreated
just prior.

apply obtain_device_list_from_udev to all libudev usage

udev_dev_is_md_component and udev_dev_is_mpath_component
are not used for obtaining the device list, but they still
use libudev for device info.  When there are problems with
udev, these functions can get stuck. So, use the existing
obtain_device_list_from_udev config setting to also control
whether these "is component" functions are used, which gives
us a way to avoid using libudev entirely when it's causing
problems.

cleanup: indent

man: lvmvdo component activation description

Describe component activation for VDO Data LV.

man: vdo regenerated

Correcting order of appearance of VDO description in lvcreate.

vdo: add some basic example

vdo: document types vdo and vdo-pool

vdo: complete matching with thin syntax

Just like we support for thin-pool syntax:

lvcreate --thinpool new_tpoolname -L Size vg

add same support logic with for vdo-poo:

lvcreate --vdopool new_vpoolname -L Size vg

Also move description of syntax bellow thin-pool, so it's
correctly ordered in generated man page.

lvconvert: pass force and yes options for vdo conversion

tests: rounding for pools changed to power of 2

Even with 64K chunk support, lvm2 will target power-of-2 chunks.

thin: select chunk size as power of 2

Whenever thin-pool chunk size is unspecified and left for lvm calculation
try to select the size as nearest highest power-of-2 instead of
just being a multiple of 64KiB.

cache: select chunk size as power of 2

When cache chunk size is not configured, and left for lvm deduction,
select the value which is power-of-2.

tests: use pvscan after enable_dev in process-each-duplicate-vgnames

instead of vgscan, so that new dev is recognized with hints

vgscan: drop 'take a while' message

every command does this

rpm: package lvmvdo man page

vdo: some formating updates

lv_manip: better work with PERCENT_VG modifier with lvresize

Fixing recent commit 022ebb0cfebee4ac8fdbe4e0c61e85db1038a115
Resize already has size that needs to be counted with,
otherwise upsizing operation could turn into size reduction one.

vdo: minor API cleanup

Since the parse_vdo_pool_status() become vdo_manip API part,
and there will be no 'dm' matching status parser,
the API can be simplified and closely match thin API here.

tests: vdo dmeventd resize

vdo: enable dmeventd resize

vdo: add simple wrapper for getting pool percentage

Just like with i.e. thins provide simple function for
getting percentage of VDO Pool usage (uses existing
status function).

tests: initial test for vdo resize

tests: aux fix testing for kvdo

tests: update cache test

Since migration_threshold is now protected to not be smaller
then 8*chunk_size - update tests to count with this modification.

vdo: man documenting resize

cleanup: better naming

vdo: allow resize of VDO and VDO pool volumes

Now with newer VDO kvdo target we can start to use standard mechanism
to enable resize of VDO volumes.

VDO pool can be grown.

Virtual volume grows on top of VDO pool when is not big enough.
Reduced VDOLV is calling discard for reduced areas - this can
take long time!

TODO: implement some pollable mechanism for out-of-lock TRIM.

vdo: size reduction requires VDO to be active

To be able to send discard to reduced areas - the VDO LV needs to
be active.

vdo: discard reduced area

Implement sending discard to reduced LV area.

vdo: estimate virtual size after resize

vdo: introduce function for estimation of virtual size

lv_manip: better work with PERCENT_VG modifier

When using 'lvcreate -l100%VG' and there is big disproportion between
real available space and requested setting - automatically fallback
to 100%FREE.

Difference can be seen when VG is big and already most space was
allocated, so the requestion 100%VG can end (and by spec for % modifier
it's correct) as LV with size of 1%VG.  Usually this is not a big
problem - buit in some cases - like cache-pool allocation, this
can result a big difference for chunksize selection.

With this patch it's more closely match common-sense logic without
the need of reitteration of too big changes in lvm2 core ATM.

TODO: in the future there should be allocator solving all allocations
in a single call.

dm: migration_threshold for old linked tools

Just like with precending  lvm2 device_mapper patch, ensure
that old users of libdm will also get fixed migration threshold
for caches.

dm: ensure migration_threshold is big enough

When using caches with BIG pool size (>TB) there is required
to use relatively huge chunk size.  Once the chunksize has
got over 1MiB - kernel cache target stopped writing such chunks
back on this if the migration_threshold remained on default 1MiB
(2048 sectors) size.

This patch ensure, DM layer will not let pass table line which
has not big enough migration threshold that can let pass
at least 8 chunks (independently of lvm2 metadata).

man: document dD attrs for VDO lvs

New attrs v(d)o pool and v(D) pool data.

man: initial man page for VDO support

Basic lvm2 command support for VDO.

man: missed --zero option for thin-pool creation

During man page rewrite this info got lost and remained
only for lvconvert. So restore it back for lvcreate.

vdo: update vdo profile

vdo: fix archived metadata comment

lvm uses 'minimum_io_size' name to exactly match  VDO naming here,
however in all common cases  _size  is using 'sector/512b' unit.
But in this case the value is in bytes and can have only 2 values:
either 512 or 4096.

It's probably not worth to rename it internaly, so we can just
drop comment - instead of using 1 or 8.

Thought let's think about it....

lvmdbusd:  Use UUID instead of name for VG rename

Use the UUID to specify the VG to rename instead of the name as this
approach works when we have duplicate VG names.

lvmdbusd: Handle duplicate VG names

Lvm can at times have duplicate names.  When this happens the daemon will
internally use vg_name:vg_uuid as the name for lookups, but display just
the vg_name externally.  If an API user uses the Manager.LookUpByLvmId and
queries the vg name they will only get returned one result as the API
can only accommodate returning 1.  The one returned is the first instance
found when sorting the volume groups by UUID.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1583510

lvmdbusd: Correct object manager lookups

When we have two logical volumes which switch their names at the
same time we are left with incorrect lookups.  Anytime we find
an entry by doing a lookup by UUID or by name we will ensure
that the lookups are indeed correct.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1642176