1
0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-23 21:35:29 +03:00
Commit Graph

508 Commits

Author SHA1 Message Date
Zdenek Kabelac
872d5922e1 cleanup: indent and dots 2016-03-01 14:02:43 +01:00
Zdenek Kabelac
8173c2ff9a coverity: missing error path 2016-03-01 14:02:43 +01:00
David Teigland
045d086a57 pvcreate: fix error from pv_write
After a pv_write() failure, the PV wasn't being skipped.
2016-02-25 16:40:24 -06:00
David Teigland
172bad0d56 Use a common message for a used PV
Change some inconsistent messages and adopt
the new wording "PV %s is used by" in place
of "PV %s is marked as belonging to"
or "PV %s belongs to".
2016-02-25 14:23:41 -06:00
David Teigland
a77ded3001 replace pvcreate_params with pvcreate_each_params
"pvcreate_each_params" was a temporary name used
to transition from the old "pvcreate_params".

Remove the old pvcreate_params struct and rename the
new pvcreate_each_params struct to pvcreate_params.
Rename various pvcreate_each_params terms to simply
pvcreate_params.
2016-02-25 09:14:10 -06:00
David Teigland
4de6caf5b5 redefine pvcreate structs
New pv_create_args struct contains all the specific
parameters for creating a PV, independent of the
command.
2016-02-25 09:14:10 -06:00
David Teigland
04d34da706 pvremove: use common toollib processing code
Use the new pvcreate_each_device() function from
toollib.
2016-02-25 09:14:09 -06:00
David Teigland
30c69b3f8a toollib: remove unsed pvcreate params function
which has been replaced by an equivalent pvcreate_each params
function.
2016-02-25 09:14:09 -06:00
David Teigland
71671778ab toollib: add two phase pv processing code
This is common code for handling PV create/remove
that can be shared by pvcreate/vgcreate/vgextend/pvremove.
This does not change any commands to use the new code.

- Pull out the hidden equivalent of process_each_pv
  into an actual top level process_each_pv.

- Pull the prompts to the top level, and do not
  run any prompts while locks are held.
  The orphan lock is reacquired after any prompts are
  done, and the devices being created are checked for
  any change made while the lock was not held.

Previously, pvcreate_vol() was the shared function for
creating a PV for pvcreate, vgcreate, vgextend.
Now, it will be toollib function pvcreate_each_device().

pvcreate_vol() was called effectively as a helper, from
within vgcreate and vgextend code paths.
pvcreate_each_device() will be called at the same level
as other process_each functions.

One of the main problems with pvcreate_vol() is that
it included a hidden equivalent of process_each_pv for
each device being created:

  pvcreate_vol() -> _pvcreate_check() ->

   find_pv_by_name() -> get_pvs() ->

     get_pvs_internal() -> _get_pvs() -> get_vgids() ->

       /* equivalent to process_each_pv */
       dm_list_iterate_items(vgids)
         vg = vg_read_internal()
         dm_list_iterate_items(&vg->pvs)

pvcreate_each_device() reorganizes the code so that
each-VG-each-PV loop is done once, and uses the standard
process_each_pv function at the top level of the function.
2016-02-25 09:14:09 -06:00
Peter Rajnoha
099d99975c cleanup: make the message about marked PVs consistent with the others 2016-02-15 15:20:23 +01:00
Peter Rajnoha
cc9e683adc toollib: skip PV if system ID is used and PV marked as used but metadata missing
If we know that a PV belongs to some VG and we're missing metadata
(because we have only those PV(s) from VG present in the system that
don't have metadata areas), we should skip such PV when processing
under system ID.

This is because we know that the PV belongs to some VG, but we
really can't decide whether it matches system ID unless the VG
metadata is present again.
2016-02-15 15:17:36 +01:00
Peter Rajnoha
d97f1c89de metadata: _vg_read: check if PV_EXT_USED flag is set correctly for orphan PVs and do a repair if needed
If we know that the PV is orphan, meaning there's at least one MDA on
that PV which does not reference any VG and at the same time there's
PV_EXT_USED flag set, we're certainly in an inconsistent state and we
need to fix this.

For example, such situation can happen during vgremove/vgreduce if we
removed/reduced the VG, but we haven't written PV headers yet because
vgremove stopped abruptly for whatever reason just before writing new
PV headers with updated state, including PV extension flags (and so the
PV_EXT_USED flag).

However, in case the PV has no MDAs at all, we can't double-check
whether the PV_EXT_USED is correct or not - if that PV is marked
as used, it's either:
  - really used (but other disks with MDAs are missing)
  - or the error state as described above is hit

User needs to overwrite the PV header directly if it's really clear
the PV having no MDAs does not belong to any VG and at the same time
it's still marked as being in use (pvcreate -ff <dev_name> will fix this).

For example - /dev/sda here has 1 MDA, orphan and is incorrectly marked
with PV_EXT_USED flag:

$ pvs --binary -o+pv_in_use
  WARNING: Found inconsistent standalone Physical Volumes.
  WARNING: Repairing flag incorrectly marking Physical Volume /dev/sda as used.
  PV         VG     Fmt  Attr PSize   PFree   InUse
  /dev/sda          lvm2 ---  128.00m 128.00m     0
2016-02-15 12:44:46 +01:00
Ondrej Kozina
0daf9d7ac5 pvmove: fix possible memory pool corruption
This is a hotfix for a bug introduced in
6d7dc87cb3.

The bug description: First we allocate memory for
processing handle (at an address 1) then we
allocate some memory on the same pool for later use
in pvmove_poll function inside the process_each_pv
function (at an address 2). After we jump out of
process_each_pv we called destroy_processing_handle.
As a result of destroying the handle memory pool could
deallocate all memory at address 1 or higher. The
pvmove_poll function tried to copy a memory allocated
at address 2 that could be returned to the system.
If it was so it led to segfault.

We need to rethink proper fix but in the same time
cmd->mem pool is recreated per each lvm command so
this should not cause problems even when we run
multiple commands in lvm shell.

A valgrind snapshot of the corruption:

Invalid read of size 1
    at 0x4C29F92: strlen (mc_replace_strmem.c:403)
    by 0x5495F2E: dm_pool_strdup (pool.c:51)
    by 0x1592A7: _create_id (pvmove.c:774)
    by 0x159409: pvmove_poll (pvmove.c:796)
    by 0x1599E3: pvmove (pvmove.c:931)
    by 0x15105B: lvm_run_command (lvmcmdline.c:1655)
    by 0x1523C3: lvm2_main (lvmcmdline.c:2121)
    by 0x1754F3: main (lvm.c:22)
Address 0xf15df8a is 138 bytes inside a block of size 8,192 free'd
    at 0x4C28430: free (vg_replace_malloc.c:446)
    by 0x5494E73: dm_free_wrapper (dbg_malloc.c:357)
    by 0x5495DE2: _free_chunk (pool-fast.c:318)
    by 0x549561C: dm_pool_free (pool-fast.c:151)
    by 0x164451: destroy_processing_handle (toollib.c:1837)
    by 0x1598C1: pvmove (pvmove.c:903)
    by 0x15105B: lvm_run_command (lvmcmdline.c:1655)
    by 0x1523C3: lvm2_main (lvmcmdline.c:2121)
    by 0x1754F3: main (lvm.c:22)
2016-02-12 11:40:33 +01:00
Zdenek Kabelac
347575df1d toollib: restore command break support
Fix regression caused by c9f021de0b.
This commit actually transfered real-action (e.g. device removal)
into the next loop which has however missed to check for break.
So add check for break also there.
2016-01-21 13:29:07 +01:00
Zdenek Kabelac
c701d9cc8c toollib: use cmd mempool for list
When creating a list in 'context of command' - use proper mempool.

vg->vgmem is mempool related to VG metadata - and can be eventually
locked read-only when VG struct is shared.
2016-01-21 13:28:28 +01:00
Zdenek Kabelac
fcbef05aae doc: change fsf address
Hmm rpmlint suggest fsf is using a different address these days,
so lets keep it up-to-date
2016-01-21 12:11:37 +01:00
Zdenek Kabelac
21028a7903 cleanup: reformat sentence about max sizes
The extent size must fits all blocks in 4294967295 sectors
(in 512b units) this is 1/2 KiB less then 2TiB.

So while previous statement 'suggested' 2TiB is still acceptable value,
make it clear it's not.

As now we support any multiples of 128KB as extent size -
values like 2047G will still 'flow-in' otherwise the largest power-of-2
supported value is 1TiB.

With 1TiB user needs 8388608 extents for 8EiB device.
(FYI such device is already unusable with todays glibc-2.22.90-27)

4GiB extent size is currently the smallest extent size which allows
a user to create 8EiB devices (with 2GiB  it's less then 8EiB).

TODO: lvm2 may possibly print amount of 'lost/unused space' on a PV,
since using such ridiculously sized extent size may result in huge
space being left unaccessible.
2016-01-20 13:44:47 +01:00
David Teigland
6b3e402298 toollib: add comment about missing device
Add a comment in _process_pvs_in_vg() to document the
place where there have been problems with processing
PVs twice.

For a while we had a hacky workaround here where we'd
skip processing a PV if its device wasn't found in
all_devices (and !is_missing_pv since we want to
process PVs with missing devices.).  That workaround
was removed in commit 5cd4d46f because it was no
longer needed.

The workaround had originally been needed to prevent
a device from being processed twice when the PV had
no MDAs -- it would be processed once in its real VG
and then the workaround would prevent it from being
processed a second time in the orphan VG.

Wrongly appearing as an orphan likely happened because
lvmcache would consider the no-MDA PV an orphan unless
the real VG holding that PV was also in lvmcache.
This issue is also mentioned in pvchange where holding
the global lock allows VGs to remain in lvmcache so
PVs with 0 mdas are not considered orphans.

The workaround in _process_pvs_in_vg() was originally
intended for reporting commands, not for pvchange.
But, it was accidentally helping pvchange also because
the method described by the pvchange global lock
comment had been subverted by commit 80f4b4b8.
Commit 80f4b4b8 was found to be unnecessary, and was
reverted in commit e710bac0.  This restored the
intended global lock lvmcache effect to pvchange, and
it no longer relied on the workaround in toollib.
2016-01-18 16:09:22 -06:00
David Teigland
5cd4d46f30 Revert "Revert "process_each_pv: remove unnecessary workaround""
This reverts commit 6d09c8c2c4.

Try again to remove the workaround.
2016-01-18 09:36:55 -06:00
David Teigland
6d09c8c2c4 Revert "process_each_pv: remove unnecessary workaround"
This reverts commit be1b1f3d89.
2016-01-14 09:12:57 -06:00
David Teigland
be1b1f3d89 process_each_pv: remove unnecessary workaround
The problem addressed by this workaround no longer
seems to exist, so remove it.  PVs with no mdas
no longer appear in both their actual VG and in
the orphan VG.
2016-01-13 10:46:04 -06:00
David Teigland
796461a912 vgrename: use process_each_vg
Use process_each_vg() to lock and read the old VG,
and then call the main vgrename code.

When real VG names are used (not a UUID in place of the
old name), the command still pre-locks the new name
(when strcmp wants it locked first), before calling
process_each_vg on the old name.

In the case where the old name is replaced with a UUID,
process_each_vg now translates that UUID into the real
VG name, which it locks and reads.  In this case, we
cannot do pre-locking to maintain lock ordering because
the old name is unknown.  So, in this case the strcmp
based lock ordering is suppressed and the old name is
always locked first.  This opens a remote chance for
lock ordering conflict between racing vgrenames between
two names where one or both commands use the UUID.
2015-12-14 14:26:47 -06:00
Alasdair G Kergon
37bd35bc3d pvscan: Remove duplicate filter wipe.
Also always clear the internal lvmcache after rescanning, and
reinstate a test for --trustcache so that 'pvs --trustcache'
(for example) avoids rescanning.
2015-12-14 20:14:59 +00:00
David Teigland
92e1422707 process_each_pv: do full scan earlier to find new devices
Before commit c1f246fedf,
_get_all_devices() did a full device scan before
get_vgnameids() was called.  The full scan in
_get_all_devices() is from calling dev_iter_create(f, 1).
The '1' arg forces a full scan.

By doing a full scan in _get_all_devices(), new devices
were added to dev-cache before get_vgnameids() began
scanning labels.  So, labels would be read from new devices.
(e.g. by the first 'pvs' command after the new device appeared.)

After that commit, _get_all_devices() was called
after get_vgnameids() was finished scanning labels.
So, new devices would be missed while scanning labels.
When _get_all_devices() saw the new devices (after
labels were scanned), those devices were added to
the .cache file.  This meant that the second 'pvs'
command would see the devices because they would be
in .cache.

Now, the full device scan is factored out of
_get_all_devices() and called by itself at the
start of the command so that new devices will
be known before get_vgnameids() scans labels.
2015-12-14 10:02:29 -06:00
Zdenek Kabelac
20483ead5b cleanup: use try_id_read_format
Better then using log_suppress in this case.
2015-12-03 18:00:54 +01:00
David Teigland
61573bd197 toollib: only interpret vgname arg as uuid for vgrename
In general, --select should be used to specify a VG by UUID,
but vgrename already allows a uuid to be substituted for
the name, so continue to allow it in that case.
2015-12-01 15:50:14 -06:00
David Teigland
166adf0e1f toollib: allow VG UUID to be used in place of VG name
If the VG arg from the command line does not match the
name of any known VGs, then check if the arg looks like
a UUID.  If it's a valid UUID, then compare it to the
UUID of known VGs.  If it matches the UUID of a known VG,
then process that VG.
2015-12-01 12:08:24 -06:00
David Teigland
ea74215fa1 vgextend: pass single vgname as process_each_vg arg
Pass the single vgname as a new process_each_vg arg
instead of setting a cmd flag to tell process_each_vg
to take only the first vgname arg from argv.

Other commands with different argv formats will be
able to use it this way.
2015-12-01 09:36:45 -06:00
David Teigland
1e43ec15ce toollib: remove unused function 2015-12-01 09:10:01 -06:00
David Teigland
aa4932674a process_each: resolve duplicate VG names
If two different VGs with the same name exist on the system,
a command that just specifies that ambiguous name will fail
with a new error:

$ vgs -o name,uuid
  ...
  foo qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf
  foo vfhKCP-mpc7-KLLL-Uh08-4xPG-zLNR-4cnxJX

$ lvs foo
  Multiple VGs found with the same name: foo
  Use the --select option with VG UUID (vg_uuid).

$ vgremove foo
  Multiple VGs found with the same name: foo
  Use the --select option with VG UUID (vg_uuid).

$ lvs -S vg_uuid=qyUS65-vn32-TuKs-a8yF-wfeQ-7DkF-Fds0uf
  lv1 foo ...

This is implemented for process_each_vg/lv, and works
with or without lvmetad.  It does not work for commands
that do not use process_each.

This change includes one exception to the behavior shown
above.  If one of the VGs is foreign, and the other is not,
then the command assumes that the intended VG is the local
one and uses it.
2015-12-01 09:09:55 -06:00
David Teigland
4ff2583dc5 process_each: always use list of vgnames on system
This makes process_each_vg/lv always use the list of
vgnames on the system.  When specific VGs are named on
the command line, the corresponding entries from
vgnameids_on_system are moved to vgnameids_to_process.

Previously, when specific VGs were named on the command
line, the vgnameids_on_system list was not created, and
vgnameids_to_process was created from the arg_vgnames
list (which is only names, without vgids).

Now, vgnameids_on_system is always created, and entries
are moved from that list to vgnameids_to_process -- either
some (when arg_vgnames specifies only some), or all (when
the command is processing all VGs, or needs to look at
all VGs for checking tags/selection).

This change adds one new lvmetad lookup (vg_list) to a
command that specifies VG names.  It adds no new work
for other commands, e.g. non-lvmetad commands, or
commands that look at all VGs.

When using lvmetad, 'lvs foo' previously sent one
request to lvmetad: 'vg_lookup foo'.
Now, 'lvs foo' sends two requests to lvmetad:
'vg_list' and 'vg_lookup foo <uuid>'.

(The lookup can now always include the uuid in the request
because the initial vg_list contains name/vgid pairs.)
2015-12-01 09:09:49 -06:00
Zdenek Kabelac
67b4761bc3 toollib: add missing check for lvmcache_init()
Coverity notices lvmcache_init() may fail so check and
error out in case of failure.
2015-11-09 10:19:20 +01:00
David Teigland
5886ff64eb pvs: don't treat duplicate PVs as missed
The recent addition to check for PVs that were
missed during the first iteration of processing
was unintentionally catching duplicate PVs because
duplicates were not removed from the all_devices
list when the primary dev was processed.

Also change a message from warn back to verbose.
2015-10-27 12:03:57 -05:00
David Teigland
a4418b34c1 vgs, lvs: ignore error if VG is removed
If a VG is removed between the time that 'vgs'
or 'lvs' (with no args) creates the list of VGs
and the time that it reads the VG to process it,
then ignore the removed VG; don't report an error
that it could not be found, since it wasn't named
by the command.
2015-10-27 10:52:01 -05:00
David Teigland
44ba862674 toollib: fix wrong paren placement 2015-10-26 16:27:26 -05:00
David Teigland
6624833839 pvs: fix missing PVs when VG is removed
PVs could be missing from the 'pvs' output if
their VG was removed at the same time that the
'pvs' command was run.  To fix this:

1. If a VG is not found when processed, don't
silently skip the PVs in it, as is done when
the "skip" variable is set.

2. Repeat the VG search if some PVs are not
found on the first search through all VGs.
The second search uses a specific list of
PVs that were missed the first time.

testing:
/dev/sdb is a PV
/dev/sdd is a PV
/dev/sdg is not a PV

each test begins with:
vgcreate test /dev/sdb /dev/sdd

variations to test:
vgremove -f test & pvs
vgremove -f test & pvs -a
vgremove -f test & pvs /dev/sdb /dev/sdd
vgremove -f test & pvs /dev/sdg
vgremove -f test & pvs /dev/sdb /dev/sdg

The pvs command should always display /dev/sdb
and /dev/sdd, either as a part of VG test or not.

The pvs command should always print an error
indicating that /dev/sdg could not be found.
2015-10-26 16:07:12 -05:00
David Teigland
8f269697d2 vg_read: remove unused inconsistent check
Commit 1a74171ca5 added
a check to ignore a VG that was FAILED_INCONSISTENT
if the command doesn't care if the VG is not found.
Remove that check because that case is never reached
by the current code.
2015-10-23 12:19:11 -05:00
David Teigland
98d81a43ea vgextend: fix use of the wrong flag
The ONE_VGNAME_ARG was being passed and tested as
vg_read() flag but it's a cmd struct flag.

(It affects command arg processing in toollib,
not vg_read behavior.  Flags related to command
processing are generally cmd struct flags, while
vg_read arg flags are generally related to vg_read
behavior.)
2015-10-23 10:21:06 -05:00
David Teigland
1a74171ca5 vg_read: sometimes ignore read errors
Running "vgremove -f VG & pvs" results in the pvs
command reporting that the VG is not found or is
inconsistent.  If the VG is gone or being removed,
the pvs command should just skip it and not print
errors about it.

"Not found" is because the pvs command created the
list of VGs to process, including VG, then vgremove
removed the VG, then the pvs command came to to read
the VG to process it and did not find it.

An "inconsistent" error could be reported if vgremove
had only partially completed removing VG when pvs did
vg_read on the VG to process it, causing pvs to find
the VG in a partially-removed state.

This fix adds a flag that pvs uses to ignore a VG
that can't be read or is inconsistent.
2015-10-23 10:12:34 -05:00
David Teigland
d99dd4086d vgcreate: improve error message for multiple lock managers
If 'vgcreate --shared' finds both sanlock and dlm are running,
print a more accurate error message:
"Found multiple lock managers, select one with --lock-type."

When neither is running, we still print:
"Failed to detect a running lock manager to select lock type."
2015-10-08 10:41:13 -05:00
David Teigland
09981afc1c vgcreate: allow both --shared and --lock-type options
Using --lock-type sanlock|dlm implies --shared.

Using --shared selects lock type sanlock|dlm
(by choosing the one that's running.)

Using both --shared and --lock-type sanlock|dlm should
also be allowed (--shared is just redundant information.)
2015-10-08 10:14:33 -05:00
David Teigland
7b570840cd lockd: no error when unlock fails
The unlock call will fail in expected and normal cases,
and should not cause the command to fail.  (An actual
unlock in the lock manager should never fail.)
2015-08-18 11:18:40 -05:00
Zdenek Kabelac
ae4db9f302 lockd: check for failing unlock
Avoid ignoring unlocking error.
2015-08-18 15:00:07 +02:00
Zdenek Kabelac
969ee25a74 toollib: get_cache_params
Enhance  get_cache_params() to read common cache args.
2015-08-12 14:11:18 +02:00
Zdenek Kabelac
036d90bba6 cache: add cache_policy cache_settings
Add new profilable configurables:

allocation/cache_policy
allocation/cache_settings

and mark allocation/cache_pool_chunk_size as profilable as well.

Obsolete allocation/cache_pool_cachemode and
introduce new allocation/cache_mode instead.

Rename DEFAULT_CACHE_POOL_POLICY to DEFAULT_CACHE_POLICY.
2015-08-12 14:11:16 +02:00
David Teigland
268f53ed0d lockd: fix error cases when built without lvmlockd
When lvm is built without lvmlockd support, vgcreate using a
shared lock type would succeed and create a local VG (the
--shared option was effectively ignored).  Make it fail.

Fix the same issue when using vgchange to change a VG to a
shared lock type.

Make the error messages consistent.
2015-07-16 15:22:06 -05:00
Zdenek Kabelac
e9e35b011e cache: handle policy_name separately
Keep policy name separate from policy settings and avoid
to mangling and demangling this string from same config tree.
Ensure policy_name is always defined.
2015-07-15 13:10:22 +02:00
David Teigland
681f779a3c lockd: fix error message after a failing to get lock
There are two different failure conditions detected in
access_vg_lock_type() that should have different error
messages.  This adds another failure flag so the two
cases can be distinguished to avoid printing a misleading
error message.
2015-07-14 11:36:04 -05:00
David Teigland
143a9d7ee6 toollib: skip processing the sanlock LV unless named or all
This prevents 'lvremove vgname' from attempting to remove the
hidden sanlock LV.  Only vgremove should remove the hidden
sanlock LV holding the sanlock locks.
2015-07-08 10:27:21 -05:00
Peter Rajnoha
3ec4813ba2 coverity: fix missing initialization
... Using uninitialized value "lockd_state" when calling "lockd_vg"
(even though lockd_vg assigns 0 to the lockd_state, but it looks at
previous state of lockd_state just before that so we need to have
that properly initialized!)

libdm/libdm-report.c:2934: uninit_use_in_call: Using uninitialized value "tm". Field "tm.tm_gmtoff" is uninitialized when calling "_get_final_time".

daemons/lvmlockd/lvmlockctl.c:273: uninit_use_in_call: Using uninitialized element of array "r_name" when calling "format_info_r_action". (just added FIXME as this looks unfinished?)
2015-07-08 14:53:30 +02:00
Alasdair G Kergon
dfe3eb12d0 include: Standardise around new tool.h. 2015-07-06 17:30:18 +01:00
David Teigland
fe70b03de2 Add lvmlockd 2015-07-02 15:42:26 -05:00
Alasdair G Kergon
4c629a5257 locking: Add missing error handling.
Add missing error logging and detection to unlock_vg and callers
of sync_local_dev_names etc.
2015-06-30 18:54:38 +01:00
David Teigland
e043e03cd8 lv_refresh: move the bulk of the function into lib
So that it can be used from other lib code.
2015-06-16 13:38:40 -05:00
Zdenek Kabelac
e047f04394 cleanup: remove extraneous parentheses 2015-05-09 09:17:26 +02:00
David Teigland
8e509b5dd5 toollib: avoid repeated lvmetad vg_lookup
In process_each_{vg,lv,pv} when no vgname args are given,
the first step is to get a list of all vgid/vgname on the
system.  This is exactly what lvmetad returns from a
vg_list request.  The current code is doing a vg_lookup
on each VG after the vg_list and populating lvmcache with
the info for each VG.  These preliminary vg_lookup's are
unnecessary, because they will be done again when the
processing functions call vg_read.  This patch eliminates
the initial round of vg_lookup's, which can roughly cut in
half the number of lvmetad requests and save a lot of extra work.
2015-05-08 11:44:55 -05:00
Ondrej Kozina
76a0dffe6f polldaemon: refactor polling interfaces
Routines responsible for polling of in-progress pvmove, snapshot merge
or mirror conversion each used custom lookup functions to find vg and
lv involved in polling.

Especially pvmove used pvname to lookup pvmove in-progress. The future
lvmpolld will poll each operation by vg/lv name (internally by lvid).
Also there're plans to make pvmove able to move non-overlaping ranges
of extents instead of single PVs as of now. This would also require
to identify the opertion in different manner.

The poll_operation_id structure together with daemon_parms structure they
identify unambiguously the polling task.
2015-05-05 20:52:07 +02:00
Ondrej Kozina
b120454b50 toollib: code cleanup in lv_spawn_background_polling
we're going to extract parameters from lv_mirr later
with code refactoring of polldaemon
2015-04-29 17:10:37 +02:00
David Teigland
0d0d50182d toollib: fix duplicate handling in process_each_pv
With use_lvmetad=0, duplicate PVs /dev/loop0 and /dev/loop1,
where in this example, /dev/loop1 is the cached device
referenced by pv->dev, the command 'pvs /dev/loop0' reports:

Failed to find physical volume "/dev/loop0".

This is because the duplicate PV detection by pvid is
not working because _get_all_devices() is not setting
any dev->pvid for any entries.  This is because the
pvid information has not yet been saved in lvmcache.
This is fixed by calling _get_vgnameids_on_system()
before _get_all_devices(), which has the effect of
caching the necessary pvid information.

With this fix, running pvs /dev/loop0, or pvs /dev/loop1,
produces no error and one line of output for the PV (the
device printed is the one cached in pv->dev, in this
example /dev/loop1.)

Running 'pvs /dev/loop0 /dev/loop1' produces no error
and two lines of output, with each device displayed
on one of the lines.

Running 'pvs -a' shows two PVs, one with loop0 and one
with loop1, and both shown as a member of the same VG.

Running 'pvs' shows only one of the duplicate PVs,
and that shows the device cached in pv->dev (loop1).

The above output is what the duplicate handling code
was previously designed to output in commits:

b64da4d8b5 toollib: search for duplicate PVs only when needed
3a7c47af0e toollib: pvs -a should display VG name for each duplicate PV
57d74a45a0 toollib: override the PV device with duplicates
c1f246fedf toollib: handle duplicate pvs in process_in_pv

As a further step after this, we may choose to change
some of those.

For all of these commands, a warning is printed about
the existence of the duplicate PVs:

Found duplicate PV ...: using /dev/loop1 not /dev/loop0
2015-04-20 17:07:58 -05:00
Ondrej Kozina
fe30658a4d toollib: close connection to lvmetad after fork
sharing connection between parent command and background
processes spawned from parent could lead to occasional failures
due to unexpected corruption in daemon responses sent to either child
or a parent.

lvmetad issued warning about duplicate config values in request.
LVM commands occasionaly failed w/ internal error after receving
corrupted response.

lvmetad connection is renewed when needed after explicit disconnect
in child
2015-04-13 20:52:32 +02:00
Ondrej Kozina
c26d81d6e6 toollib: do not spawn polling in lv_change_activate
spawning a background polling from within the lv_change_activate
fn went to two problems:

1) vgchange should not spawn any background polling until after
   the whole activation process for a VG is finished. Otherwise
   it could lead to a duplicite request for spawning background
   polling. This statement was alredy true with one exception of
   mirror up-conversion polling (fixed by this commit).

2) due to current conditions in lv_change_activate lvchange cmd
   couldn't start background polling for pvmove LVs if such LV was
   about to get activated by the command in the same time.

This commit however doesn't alter the lvchange cmd so that it works same as
vgchange with regard to not to spawn duplicate background pollings per
unique LV.
2015-04-13 20:52:22 +02:00
Peter Rajnoha
8759f7d755 metadata: vg: add removed_lvs field to collect LVs which have been removed
Do not keep dangling LVs if they're removed from the vg->lvs list and
move them to vg->removed_lvs instead (this is actually similar to already
existing vg->removed_pvs list, just it's for LVs now).

Once we have this vg->removed_lvs list indexed so it's possible to
do lookups for LVs quickly, we can remove the LV_REMOVED flag as
that one won't be needed anymore - instead of checking the flag,
we can directly check the vg->removed_lvs list if the LV is present
there or not and to say if the LV is removed or not then. For now,
we don't have this index, but it may be implemented in the future.
2015-03-24 08:43:08 +01:00
Peter Rajnoha
c9f021de0b metadata: process_each_lv_in_vg: get the list of LVs to process first, then do the processing
This avoids a problem in which we're using selection on LV list - we
need to do the selection on initial state and not on any intermediary
state as we process LVs one by one - some of the relations among LVs
can be gone during this processing.

For example, processing one LV can cause the other LVs to lose the
relation to this LV and hence they're not selectable anymore with
the original selection criteria as it would be if we did selection
on inital state. A perfect example is with thin snapshots:

$ lvs -o lv_name,origin,layout,role vg
  LV    Origin Layout      Role
  lvol1        thin,sparse public,origin,thinorigin,multithinorigin
  lvol2 lvol1  thin,sparse public,snapshot,thinsnapshot
  lvol3 lvol1  thin,sparse public,snapshot,thinsnapshot
  pool         thin,pool   private

$ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1'
  Logical volume "lvol1" successfully removed

The lvremove command above was supposed to remove lvol1 as well as
all its snapshots which have origin=lvol1. It failed to do so, because
once we removed the origin lvol1, the lvol2 and lvol3 which were
snapshots before are not snapshots anymore - the relations change
as we're processing these LVs one by one.

If we do the selection first and then execute any concrete actions on
these LVs (which is what this patch does), the behaviour is correct
then - the selection is done on the *initial state*:

$ lvremove -ff -S 'lv_name=lvol1 || origin=lvol1'
  Logical volume "lvol1" successfully removed
  Logical volume "lvol2" successfully removed
  Logical volume "lvol3" successfully removed

Similarly for all the other situations in which relations among
LVs are being changed by processing the LVs one by one.

This patch also introduces LV_REMOVED internal LV status flag
to mark removed LVs so they're not processed further when we
iterate over collected list of LVs to be processed.

Previously, when we iterated directly over vg->lvs list to
process the LVs, we relied on the fact that once the LV is removed,
it is also removed from the vg->lvs list we're iterating over.
But that was incorrect as we shouldn't remove LVs from the list
during one iteration while we're iterating over that exact list
(dm_list_iterate_items safe can handle only one removal at
one iteration anyway, so it can't be used here).
2015-03-24 08:43:07 +01:00
Alasdair G Kergon
19c3851d9c toollib: Reorder process_each_pv initialisation.
Perform cheaper command line-based validation before more-expensive
processing and scanning.
2015-03-18 23:34:46 +00:00
Alasdair G Kergon
5bf74f2997 pvs: Hide inaccessible clustered PVs.
Inaccessible clustered PVs can be hidden from pvs -a in the same way as
foreign PVs, rather than showing them as if they do not belong to a VG.
2015-03-18 23:31:46 +00:00
Alasdair G Kergon
3562b5ab39 systemid: Init and merge lvm2 and lvm1 fields.
Use system_id field in preference to lvm1_system_id.
Initialise both for now.
2015-03-04 01:00:51 +00:00
David Teigland
c32efc7f7e system_id: apply consistent naming
In log messages refer to it as system ID (not System ID).

Do not put quotes around the system_id string when printing.

On the command line use systemid.

In code, metadata, and config files use system_id.

In lvmsystemid refer to the concept/entity as system_id.
2015-02-27 13:32:00 -06:00
David Teigland
0a19238aa3 system_id: remove unwanted foreign error for some commands
Commands that can never use foreign VGs begin with
cmd->error_foreign_vgs = 1.  This tells the vg_read
lib layer to print an error as soon as a foreign VG
is read.

The toollib process_each layer also prints an error if a
foreign VG is read, but is more selective about it.  It
won't print an error if the command did not explicitly
name the foreign VG.  We want to silently ignore foreign VGs
unless a command attempts to use one explicitly.

So, foreign VG errors are printed from two different layers:
vg_read (lower layer) and process_each (upper layer).

Commands that use toollib process_each, only want errors from
the process_each layer, not from both layers.  So, process_each
disables the lower layer vg_read error message by setting
error_foreign_vgs = 0.

Commands that do not use toollib process_each, want errors
from the vg_read layer, otherwise they would get no error
message.  The original cmd->error_foreign_vgs setting
enables this error.

(Commands that are allowed to operate on foreign VGs always
begin with cmd->error_foreign_vgs = 0, and all the commands
in this group use toollib process_each with the selective
error reporting.)
2015-02-26 16:33:36 -06:00
Alasdair G Kergon
809a5e142e systemid: Improve concurrent warning. 2015-02-25 14:17:35 +00:00
Alasdair G Kergon
ac6a4cd707 systemid: Allow empty systemid with warnings.
Add warning messages when empty system ID is set.
2015-02-25 14:12:24 +00:00
Petr Rockai
7d615a3fe5 cache: Fix a segfault when passing --cachepolicy without --cachesettings. 2015-02-24 11:39:35 +01:00
Alasdair G Kergon
b18feb98e5 systemid: Fix access restrictions.
When checking whether the system ID permits access to a VG, check for
each permitted situation first, and only then issue the appropriate
error message.  Always issue a message for now.  (We'll try to
suppress some of those later when the VG concerned wasn't explicitly
requested.)
Add more messages to try to ensure every return code is checked and
every error path (and only an error path) contains a log_error().
Add self-correction to vgchange -c to deal with situations where
the cluster state and system ID state are out-of-sync (e.g. if
old tools were used).
2015-02-23 23:19:36 +00:00
David Teigland
737c992431 toollib: add underscore to static ignore_vg function 2015-02-13 11:01:55 -06:00
David Teigland
8cdec4c434 system_id: use for VG ownership
See included lvmsystemid(7) for full description.
2015-02-13 10:10:27 -06:00
David Teigland
f5d06efbab vgextend: Use process_each_vg.
Tags and --select are not yet supported because new code is needed
to ensure exactly one VG matches before the VG starts to be processed.
2015-02-13 14:58:51 +00:00
Peter Rajnoha
e0ce728579 tolllib: process_each_pv: always use full_filter unconditionally when getting all devices
(This reverts patch #d95c6154)

Filter complete device list through full_filter unconditionally when
we're getting the list of *all* devices even in case we're interested
only in fraction of those devices - the PVs, not the other devices
which are not PVs yet (e.g. pvs vs. pvs -a).

We need to do this full filtering whenever we're handling *complete*
list of devices, we need to be safe here, mainly if there are any
future changes and we'd forgot to change to use proper filtering then.
Also properly preventing duplicates if there are any block subsystem
components used (mpath, MD ...).

Thing here is that (under use_lvmetad=1), cmd->filter can be used
only if we're sure that the list of devices we're filtering contains
only PVs. We have to use cmd->full_filter otherwise (like it is in
case of _get_all_devices fn which acquires complete list of devices,
no matter if it is a PV or not).

Of course, cmd->full_filter is more extensive than cmd->filter
which is only a subset of full_filter.

We could optimize this in a way that if we're interested in PVs only
during process_each_pv processing (e.g. using pvs in contrast to pvs -a),
we'd get the list of PV devices directly from lvmetad from the
lvmcache_seed_infos_from_lvmetad fn call which currently updates
lvmcache only. We'd add an additional output arg for this fn to get
the list of PV devices directly in addition, without a need to iterate
over all devices which include non-PVs which we're not interested in
anyway, hence we could use only cmd->filter, not the cmd->full_filter.

So the code would look something like this:

static int _get_all_devices(....)
{
	struct device_id_list *dil;

	if (interested_in_pvs_only)
		lvmcache_seed_infos_from_lvmetad(cmd, &dil); /* new "dil" arg */
		/* the "dil" list would be filtered through cmd->filter inside lvmcache_seed_infos_from_lvmetad */
	else {
		lvmcache_seed_infos_from_lvmetad(cmd, NULL);
		dev_iter_create(cmd->full_filter)
		while (dev = dev_iter_get ...) {
			dm_list_add(all_devices, &dil->list);
		}
	}
}
2015-02-13 11:27:09 +01:00
Peter Rajnoha
969d2bf448 cleanup: remove deallocate_handle_root arg from destroy_procesing_handle fnw 2015-02-13 11:27:09 +01:00
Peter Rajnoha
66b10d6d12 cleanup: replace static struct processing_handle initializer with common init_processing_handle
It's cleaner this way - do not mix static and dynamic
(init_processing_handle) initializers. Use the dynamic one everywhere.
This makes it easier to manage the code - there are no "exceptions"
then and we don't need to take care about two ways of initializing the
same thing - just use one common initializer throughout and it's clear.

Also, add more comments, mainly in the report_for_selection fn explaining
what is being done and why with respect to the processing_handle and
selection_handle.
2015-02-13 11:26:57 +01:00
Peter Rajnoha
d95c6154ff toollib: process_each_pv: fix commit d38d047e which worked for processing "all devices", but didn't work for "all PVs"
We still need to get the list as the calls underneath process_each_pv
rely on this list. But still keep the change related to the filters -
if we're processing all devices, we need to use cmd->full_filter.
If we're processing only PVs, we can use cmd->filter only to save
some time which would be spent in filtering code.
2015-02-12 14:14:45 +01:00
Peter Rajnoha
e52c998c49 toollib: process_each_pv: use cmd->full_filter, not cmd->filter if we're getting full list of PV-capable devices (not just PVs)
When lvmetad is used and at the same time we're getting list of all
PV-capable devices, we can't use cmd->filter (which is used to filter
out lvmetad responses - so we're sure that the devices are PVs already).

To get the list of PV-capable devices, we're bypassing lvmetad (since
lvmetad only caches PVs, not all the other devices which are not PVs).
For this reason, we have to use the "full_filter" filter chain (just
like we do when we're running without lvmetad).

Example scenario:
- sdo and sdp components of MD device md0
- sdq, sdr and sds components of mpatha multipath device
- mpatha multipath device partitioned
- vda device partitioned

=> sdo,sdp,sdr,sds, mpatha and vda should be filtered!

$ lsblk -o NAME,TYPE
NAME            TYPE
sdn             disk
sdo             disk
`-md0           raid0
sdp             disk
`-md0           raid0
sdq             disk
`-mpatha        mpath
  `-mpatha1     part
sdr             disk
`-mpatha        mpath
  `-mpatha1     part
sds             disk
`-mpatha        mpath
  `-mpatha1     part
vda             disk
|-vda1          part
`-vda2          part
  |-fedora-swap lvm
  `-fedora-root lvm

Before this patch:
==================
use_lvmetad=0 (correct behaviour!)
$ pvs -a
  PV                  VG     Fmt  Attr PSize PFree
  /dev/fedora/root                ---     0     0
  /dev/fedora/swap                ---     0     0
  /dev/mapper/mpatha1             ---     0     0
  /dev/md0                        ---     0     0
  /dev/sdn                        ---     0     0
  /dev/vda1                       ---     0     0
  /dev/vda2           fedora lvm2 a--  9.51g    0

use_lvmetad=1 (incorrect behaviour - sdo,sdp,sdq,sdr,sds and mpatha not filtered!)
$ pvs -a
  PV                  VG     Fmt  Attr PSize PFree
  /dev/fedora/root                ---     0     0
  /dev/fedora/swap                ---     0     0
  /dev/mapper/mpatha              ---     0     0
  /dev/mapper/mpatha1             ---     0     0
  /dev/md0                        ---     0     0
  /dev/sdn                        ---     0     0
  /dev/sdo                        ---     0     0
  /dev/sdp                        ---     0     0
  /dev/sdq                        ---     0     0
  /dev/sdr                        ---     0     0
  /dev/sds                        ---     0     0
  /dev/vda                        ---     0     0
  /dev/vda1                       ---     0     0
  /dev/vda2           fedora lvm2 a--  9.51g    0

With this patch applied:
========================
use_lvmetad=1
$ pvs -a
  PV                  VG     Fmt  Attr PSize PFree
  /dev/fedora/root                ---     0     0
  /dev/fedora/swap                ---     0     0
  /dev/mapper/mpatha1             ---     0     0
  /dev/md0                        ---     0     0
  /dev/sdn                        ---     0     0
  /dev/vda1                       ---     0     0
  /dev/vda2           fedora lvm2 a--  9.51g    0
2015-02-12 13:46:11 +01:00
Peter Rajnoha
d38d047eec toollib: process_each_pv: do not acquire list of all devices if not necessary
List of all devices is only needed if we want to process devices
which are not PVs (e.g. pvs -a). But if this is not the case, it's
useless to get the list of all devices and then discard it without
any use, which is exactly what happened in process_each_pv where
the code was never reached and the list was unused if we were
processing just PVs, not all PV-capable devices:

int process_each_pv(...)
{
	...
	process_all_devices = process_all_pvs &&
			      (cmd->command->flags & ENABLE_ALL_DEVS) &&
			      arg_count(cmd, all_ARG);
	...
	/*
	 * If the caller wants to process all devices (not just PVs), then all PVs
	 * from all VGs are processed first, removing them from all_devices.  Then
	 * any devs remaining in all_devices are processed.
	*/
	_get_all_devices(cmd, &all_devices);
	...
	ret = _process_pvs_in_vgs(...);
	...
	if (!process_all_devices)
		goto out;

        ret = _process_device_list(cmd, &all_devices, handle, process_single_pv);
	...
}

This patch adds missing check for "process_all_devices" and it gets the
list of all (including non-PV) devices only if needed:
2015-02-12 13:46:11 +01:00
Peter Rajnoha
bc1bb7f8c5 toollib: select: issue an error message for failed VG/LV/PV selection 2015-02-11 09:36:09 +01:00
Peter Rajnoha
7f2eebf519 select: initialize selection handle for process_each_* fns with initial report type
This is a followup patch for previous patchset that enables selection in
process_each_* fns to fix an issue where field prefixes are not
automatically used for fields in selection criteria.

Use initial report type that matches the intention of each process_each_* functions:
- _process_pvs_in_vg - PVS
- process_each_vg - VGS
- process_each_lv and process_each_lv_in_vg - LVS

This is not normally needed for the selection handle init, BUT we would
miss the field prefix matching, e.g.

lvchange -ay -S 'name=lvol0'

The "name" above would not work if we didn't initialize reporting with
the LVS type at its start. If we pass proper init type, reporting code
can deduce the prefix automatically ("lv_name" in this case).

This report type is then changed further based on what selection criteria we
have. When doing pure selection, not report output, the final report type
is purely based on combination of this initial report type and report types
of the fields used in selection criteria.
2015-02-10 16:10:17 +01:00
Peter Rajnoha
984ae7f72d report: add report_for_selection and use it in select_match_{pv,vg,lv}
The report_for_selection does the actual "reporting for selection only".
The selection status will be saved in struct selection_handle's "selected"
variable.
2015-02-10 16:05:36 +01:00
Peter Rajnoha
de27324711 toollib: select the whole structure if at least one of its items is selected
This applies to:
  - process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected
  - process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected
  - process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected
  - process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected

So this patch causes the selection result to be properly propagated up to callers.
2015-02-10 16:05:32 +01:00
Peter Rajnoha
56011918e6 toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns
Call _init_processing_handle, _init_selection_handle and
_destroy_processing_handle in process_each_* and related functions to
set up and destroy handles used while processing items.
2015-02-10 16:05:29 +01:00
Peter Rajnoha
a91bc7a19b toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions
The init_processing_handle, init_selection_handle and
destroy_processing_handle are helper functions that allocate and
initialize the handles used when processing items in process_each_*
and related functions.
2015-02-10 16:05:27 +01:00
Peter Rajnoha
c3180c4a05 toollib: pass struct processing_handle to _select_match_* functions
The "struct processing_handle" contains handles to drive the selection/matching
so pass it to the _select_match_* functions which are entry points to the
selection mechanism used in process_each_* and related functions.

This is revised and edited version of former Dave Teigland's patch which
provided starting point for all the select support in process_each_* fns.
2015-02-10 16:05:26 +01:00
Peter Rajnoha
51d96a1703 toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related)
This patch replaces "void *handle" with "struct processing_handle *handle"
in process_each_*, process_single_* and related functions.

The struct processing_handle consists of two handles inside now:

  - the "struct selection_handle *selection_handle" used for
    applying selection criteria while processing process_each_*,
    process_single_* and related functions (patches using this
    logic will follow)

  - the "void* custom_handle" (this is actually the original handle
    used before this patch - a pointer to custom data passed into
    process_each_*, process_single_* and related functions).
2015-02-10 16:05:24 +01:00
David Teigland
455ef6f2f5 toollib: prepare select_match_{pv,vg,lv} hooks
These hooks will check currently processed PV/VG/LV with current selection
criteria and the processing continues only if there's a match.
2015-02-10 16:04:41 +01:00
David Teigland
b64da4d8b5 toollib: search for duplicate PVs only when needed
A full search for duplicate PVs in the case of pvs -a
is only necessary when duplicates have previously been
detected in lvmcache.  Use a global variable from lvmcache
to indicate that duplicate PVs exist, so we can skip the
search for duplicates when none exist.
2015-01-14 14:47:08 -06:00
David Teigland
3a7c47af0e toollib: pvs -a should display VG name for each duplicate PV
Previously, 'pvs -a' displayed the VG name for only the device
associated with the cached PV (pv->dev), and other duplicate
devices would have a blank VG name.  This commit displays the
VG name for each of the duplicate devices.  The cost of doing
this is not small: for each PV processed, the list of all
devices must be searched for duplicates.
2015-01-14 14:16:03 -06:00
David Teigland
57d74a45a0 toollib: override the PV device with duplicates
When multiple duplicate devices are specified on the
command line, the PV is processed once for each of them,
but pv->dev is the device used each time.

This overrides the PV device to reflect the duplicate
device that was specified on the command line.  This is
done by hacking the lvmcache to replace pv->dev with the
device of the duplicate being processed.  (It would be
preferable to override pv->dev without munging the content
of the cache, and without sprinkling special cases throughout
the code.)

This override only applies when multiple duplicate devices are
specified on the command line.  When only a single duplicate
device of pv->dev is specified, the priority is to display the
cached pv->dev, so pv->dev is not overridden by the named
duplicate device.

In the examples below, loop3 is the cached device referenced
by pv->dev, and is given priority for processing.  Only after
loop3 is processed/displayed, will other duplicate devices
loop0/loop1 appear (when requested on the command line.)

With two duplicate devices, loop0 and loop3:

  # pvs
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop0
  PV         VG           Fmt  Attr PSize   PFree
  /dev/loop3 loopa        lvm2 a--   12.00m  12.00m

  # pvs /dev/loop3
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop0
  PV         VG    Fmt  Attr PSize  PFree
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m

  # pvs /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop0
  PV         VG    Fmt  Attr PSize  PFree
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m

  # pvs -o+dev_size /dev/loop0 /dev/loop3
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop0
  PV         VG    Fmt  Attr PSize  PFree  DevSize
  /dev/loop0 loopa lvm2 a--  12.00m 12.00m  16.00m
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m  32.00m

With three duplicate devices, loop0, loop1, loop3:

  # pvs -o+dev_size
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop1 not /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop1
  PV         VG           Fmt  Attr PSize   PFree   DevSize
  /dev/loop3 loopa        lvm2 a--   12.00m  12.00m  32.00m

  # pvs -o+dev_size /dev/loop3
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop1 not /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop1
  PV         VG    Fmt  Attr PSize  PFree  DevSize
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m  32.00m

  # pvs -o+dev_size /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop1 not /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop1
  PV         VG    Fmt  Attr PSize  PFree  DevSize
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m  32.00m

  # pvs -o+dev_size /dev/loop1
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop1 not /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop1
  PV         VG    Fmt  Attr PSize  PFree  DevSize
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m  32.00m

  # pvs -o+dev_size /dev/loop3 /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop1 not /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop1
  PV         VG    Fmt  Attr PSize  PFree  DevSize
  /dev/loop0 loopa lvm2 a--  12.00m 12.00m  16.00m
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m  32.00m

  # pvs -o+dev_size /dev/loop3 /dev/loop1
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop1 not /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop1
  PV         VG    Fmt  Attr PSize  PFree  DevSize
  /dev/loop1 loopa lvm2 a--  12.00m 12.00m  32.00m
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m  32.00m

  # pvs -o+dev_size /dev/loop0 /dev/loop1
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop1 not /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop1
  PV         VG    Fmt  Attr PSize  PFree  DevSize
  /dev/loop1 loopa lvm2 a--  12.00m 12.00m  32.00m
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m  32.00m

  # pvs -o+dev_size /dev/loop0 /dev/loop1 /dev/loop3
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop1 not /dev/loop0
  Found duplicate PV XhLbpVo0hmuwrMQLjfxuAvPFUFZqD4vr: using /dev/loop3 not /dev/loop1
  PV         VG    Fmt  Attr PSize  PFree  DevSize
  /dev/loop0 loopa lvm2 a--  12.00m 12.00m  16.00m
  /dev/loop1 loopa lvm2 a--  12.00m 12.00m  32.00m
  /dev/loop3 loopa lvm2 a--  12.00m 12.00m  32.00m
2015-01-14 11:57:29 -06:00
David Teigland
c1f246fedf toollib: handle duplicate pvs in process_in_pv
Processes a PV once for each time a device with its PV ID
exists on the command line.

This fixes a regression in the case where:

. devices /dev/sdA and /dev/sdB where clones (same PV ID)

. the cached VG references /dev/sdA

. before the regression, the command: pvs /dev/sdB
  would display the cached device clone /dev/sdA

. after the regression, pvs /dev/sdB would display nothing,
  causing vgimportclone /dev/sdB to fail.

. with this fix, pvs /dev/sdB displays /dev/sdA

Also, pvs /dev/sdA /dev/sdB will report two lines, one for each
device on the command line, but /dev/sdA is displayed for each.

This only works without lvmetad.
2015-01-14 11:57:29 -06:00
David Teigland
1e4a4d48ae toollib: process_each_pv should match by device
When processing PVs specified on the command line, the arg
name was being matched against pv_dev_name, which will not
always work:

- The PV specified on the command line could be an alias,
  e.g. /dev/disk/by-id/...

- The PV specified on the command line could be any random
  path to the device, e.g. /dev/../dev/sdb

To fix this, first resolve the named PV args to struct device's,
then iterate through the devices for processing.
2015-01-09 10:03:31 -06:00
Petr Rockai
9290854163 toollib: Fix uninitialised config value type in get_cachepolicy_params. 2014-11-27 20:19:28 +01:00
Zdenek Kabelac
4bfdb01f78 toollib: fix regression in parsing /dev/mapper/vg-lv
Commit b0dde9e8f0 introduced regression in parsing
/dev/mapper prefix - and tried to check for '/' one char behind.
2014-11-26 17:29:35 +01:00
Peter Rajnoha
193f9b26a0 coverity: fix possible NULL dereference
The call to dm_config_destroy can derefence result->mem
while result is still NULL:

struct dm_config_tree *get_cachepolicy_params(struct cmd_context *cmd)
{
	...
	int ok = 0;
	...
	if (!(result = dm_config_flatten(current)))
		goto_out;
	...
	ok = 1;
out:
	 if (!ok) {
		dm_config_destroy(result)
		...
	}
	...
}
2014-11-26 11:46:13 +01:00
Zdenek Kabelac
a6a7a3a074 cleanup: add missing error path check
New code misses error path check.
2014-11-23 00:49:04 +01:00
Zdenek Kabelac
089bdc0be4 cleanup: drop unused vars 2014-11-20 17:49:32 +01:00