1
0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Commit Graph

2921 Commits

Author SHA1 Message Date
David Teigland
01156de6f7 lvmcache: add optional dev arg to lvmcache_info_from_pvid
A number of places are working on a specific dev when they
call lvmcache_info_from_pvid() to look up an info struct
based on a pvid.  In those cases, pass the dev being used
to lvmcache_info_from_pvid().  When a dev is specified,
lvmcache_info_from_pvid() will verify that the cached
info it's using matches the dev being processed before
returning the info.  Calling code will not mistakenly
get info for the wrong dev when duplicate devs exist.

This confusion was happening when scanning labels when
duplicate devs existed.  label_read for the first dev
would add an info struct to lvmcache for that dev/pvid.
label_read for the second dev would see the pvid in
lvmcache from first dev, and mistakenly conclude that
the label_read from the second dev can be skipped
because it's already been done.  By verifying that the
dev for the cached pvid matches the dev being read,
this mismatch is avoided and the label is actually read
from the second duplicate.
2016-06-07 15:15:47 -05:00
David Teigland
b321d2b1b9 pvmove: disallow tag args
pvmove began processing tags unintentionally from commit,
6d7dc87cb pvmove: use toollib

pvmove works on a single PV, but tags can match multiple PVs.
If we allowed tags, but processed only the first matching PV,
then the resulting PV would be unpredictable.

Also, the current processing code does not allow us to simply
report an error and do nothing if more than one PV matches the tag,
because the command starts processing PVs as they are found,
so it's too late to do nothing if a second PV matches.
2016-06-03 09:56:48 -05:00
Peter Rajnoha
687bc5cecf lvmconfig: fix lvmconfig --type diff to display complete diff if config cascade used
If configuration consists of several sources in config cascade
("config cascade" defined in man lvmconfig(8)), lvmconfig displayed
only difference from defaults of the topmost config in the cascade.
Fix lvmconfig to display complete difference, considering all
the configuration in the cascade.

For example, before this patch:

	(use_lvmetad=0 set in lvm.conf which differs from defaults)
	$ lvmconfig --type diff
	global {
		use_lvmetad=0
	}

	(compact_output=1 set on cmd line)
	$ lvmconfig --type diff --config report/compact_output=1
	report {
		compact_output=1
	}

	(headings=0 set in profile)
	$ lvmconfig --type diff --commandprofile test
	report {
		headings=0
	}

	(difference in topmost configuration source is displayed)
	$ lvmconfig --type diff --commandprofile test --config report/compact_output=1
	report {
		compact_output=1
	}

With this patch applied (the config cascade is merged before looking for
difference from defaults in configuration):

	$ lvmconfig --type diff
	global {
		use_lvmetad=0
	}

	$ lvmconfig --type diff --config report/compact_output=1
	report {
		compact_output=1
	}
	global {
		use_lvmetad=0
	}

	$ lvmconfig --type diff --profile test
	report {
		headings=0
	}
	global {
		use_lvmetad=0
	}

	$ lvmconfig --type diff --profile test --config report/compact_output=1
	report {
		headings=0
		compact_output=1
	}
	global {
		use_lvmetad=0
	}
2016-06-02 13:49:38 +02:00
Peter Rajnoha
48877e215d coverity: missing check for id_write_format return value 2016-05-31 09:56:10 +02:00
Peter Rajnoha
4fb224a553 toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv} 2016-05-31 09:08:59 +02:00
Peter Rajnoha
815f1ee26d toollib: simplify internal selection calls for non-reporting tools
Some of the variables were set superfluously - we can just use existing
"struct processing_handle" which includes "struct selection_handle".
2016-05-30 16:44:18 +02:00
Zdenek Kabelac
04003cf1ff cache: add log_error on error path
Validate and report error when lv_cache_status is called
for inactive LV, or pending delete or unused cache_pool.
2016-05-27 15:47:24 +02:00
Zdenek Kabelac
98b41db324 cleanup: drop cmd and constify lv for lv_refresh_suspend_resume()
Like with most other lv_manip* functions take just LV arg and get cmd
from embeded pointer when needed.
2016-05-27 15:47:24 +02:00
Zdenek Kabelac
cb49ceeaba cleanup: substract integers
Instead of doing float arithmetic, do integer math first and
convert result to float.
2016-05-27 15:47:24 +02:00
David Teigland
5dc2ed0c71 vgreduce: use process_each_vg 2016-05-25 16:41:59 -05:00
David Teigland
2f2b3c9100 lvconvert: use process_each_lv
In the same way that process_each_vg() can be passed
a single VG name to process, also allow process_each_lv()
to be passed a single VG name and LV name to process.
2016-05-25 15:05:49 -05:00
Peter Rajnoha
adeb624c3b refactor: split _report fn further into init and config part 2016-05-24 10:56:57 +02:00
Alasdair G Kergon
b896f7de1e raid0: Standardise meta_areas checks before access. 2016-05-23 22:55:13 +01:00
David Teigland
9b640c3684 pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation.  Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.

Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted.  During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names.  This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.

The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-05-23 11:57:32 -05:00
David Teigland
55683a659f toollib: add vg name list arg to process_each_vg 2016-05-23 11:18:16 -05:00
Alasdair G Kergon
bf8d00985a raid0: Add raid0 segment type.
This remains experimental and quite restrictive so should only be used
for testing at this stage.  (E.g. lvreduce is not supported.)
2016-05-23 16:46:38 +01:00
David Teigland
ad4ca55543 tools: improve error message about VG name and select 2016-05-19 15:06:56 -05:00
Zdenek Kabelac
197066c863 lvchange: allow change of cache mode
Add support for active cache LV.
Handle --cachemode args validation during command line processing.
Rework some lvm2 internal to use lvm2 defined  CACHE_MODE  enums
indepently on libdm defines and use enum around the code instead
of passing and comparing strings.
2016-05-19 18:40:14 +02:00
David Teigland
ba9b7b69d9 pvremove: allow clearing a duplicate PV
Add a special case to allow modifying a duplicate PV
to erase it with pvremove -ff.
2016-05-16 14:40:43 -05:00
Peter Rajnoha
5c18b0ce9c refactor: separate original _report fn into _report and _do_report fn
The _report fn is getting big - separate it in two:

  - _report fn to get all the options and arguments
  - _do_report fn for reporting itself

Also, place all the variables/arguments in one structure for easier
handling of the variables around.
2016-05-10 14:00:13 +02:00
David Teigland
e84fb639f0 lvmetad: add duplicate resolution advice 2016-05-06 09:00:00 -05:00
David Teigland
d3d13e134a lvmcache: process duplicate PVs directly
Previously, duplicate PVs were processed as a side effect
of processing the "chosen" PV in lvmcache.  The duplicate
PV would be hacked into lvmcache temporarily in place of
the chosen PV.

In the old way, we had to always process the "chosen" PV
device, even if a duplicate of it was named on the command
line.  This meant we were processing a different device than
was asked for.  This could be worked around by naming
multiple duplicate devs on the command line in which case
they were swapped in and out of lvmcache for processing.

Now, the duplicate devs are processed directly in their
own processing loop.  This means we can remove the old
hacks related to processing dups as a side effect of
processing the chosen device.  We can now simply process
the device that was named on the command line.

When the same PVID exists on two or more devices, one device
is preferred and used in the VG, and the others are duplicates
and are not used in the VG.  The preferred device exists in
lvmcache as usual.  The duplicates exist in a specical list
of unused duplicate devices.

The duplicate devs have the "d" attribute and the "duplicate"
reporting field displays "duplicate" for them.

'pvs' warns about duplicates, but the formal output only
includes the single preferred PV.

'pvs -a' has the same warnings, and the duplicate devs are
included in the output.

'pvs <path>' has the same warnings, and displays the named
device, whether it is preferred or a duplicate.
2016-05-06 09:00:00 -05:00
David Teigland
8b7a78c728 lvmcache: improve duplicate PV handling
Wait to compare and choose alternate duplicate devices until
after all devices are scanned.  During scanning, the first
duplicate dev is kept in lvmcache, and others are kept in a
new list (_found_duplicate_devs).

After all devices are scanned, compare all the duplicates
available for a given PVID and decide which is best.

If the dev used in lvmcache is changed, drop the old dev
from lvmcache entirely and rescan the replacement dev.
Previously the VG metadata from the old dev was kept in
lvmcache and only the dev was replaced.

A new config setting devices/allow_changes_with_duplicate_pvs
can be set to 0 which disallows modifying a VG or activating
LVs in it when the VG contains PVs with duplicate devices.
Set to 1 is the old behavior which allowed the VG to be
changed.

The logic for which of two devs is preferred has changed.
The primary goal is to choose a device that is currently
in use if the other isn't, e.g. by an active LV.

. prefer dev with fs mounted if the other doesn't, else
. prefer dev that is dm if the other isn't, else
. prefer dev in subsystem if the other isn't

If neither device is preferred by these rules, then don't
change devices in lvmcache, leaving the one that was found
first.

The previous logic for preferring a device was:

. prefer dev in subsystem if the other isn't, else
. prefer dev without holders if the other has holders, else
. prefer dev that is dm if the other isn't
2016-05-06 09:00:00 -05:00
David Teigland
a1dbd54885 pvscan: fix errors for single dev scan while lvmetad is disabled
While lvmetad was disabled, 'pvscan --cache dev' would produce
confusing error messages.
2016-05-06 08:59:59 -05:00
David Teigland
7c1e601164 pvcreate: improve debug message
state what the printed UUID is.
2016-05-04 12:11:13 -05:00
David Teigland
1df6769aca pvcreate, pvremove: translate arg name to device once
Rather than doing repeated translations from name to
device when comparing args to existing PVs, do one
translation of the arg names and saving the device,
before checking existing PVs.
2016-05-04 11:28:28 -05:00
David Teigland
a2d2a61339 pvscan: autoactivation should ignore some VGs
pvscan autoactivation has its own VG processing implementation,
so it can't properly handle things like foreign or shared VGs,
so make it ignore those VG types (or errors from them) as best
as possible.

Add a FIXME stating that pvscan autoactivation must really be
moved to the standard VG processing by calling process_each_vg
to do activation once the scanning / cache update is finished.
2016-04-27 15:45:38 -05:00
Zdenek Kabelac
e77b6968b6 lvchange: use better arg functions 2016-04-26 23:29:58 +02:00
Zdenek Kabelac
c215e1be5c lvchange: always check for sigint
Check sigint() state during process_each_lv.
2016-04-26 23:29:08 +02:00
Zdenek Kabelac
d8bdc7af37 lvchange: fix return code
We already opened VG for this - so not an invalid cmdline.
2016-04-26 23:28:01 +02:00
Alasdair G Kergon
01181a299e activate: Hide errors when snapshot merge delayed. 2016-04-21 22:14:10 +01:00
David Teigland
4d095c2fbb poll daemon: only call lvmetad_connect when needed
When lvm is not using lvmetad, the lvmetad_connect()
in the forked polling process is not needed and was
generating unwanted warnings.
2016-04-21 15:58:34 -05:00
David Teigland
5c104c5de9 lvmetad: connect from forked polling process
With commit 5e9e43074a, lvmetad connections are
now made explicitly, so a new connection must be
created from a child created for polling.
2016-04-20 09:04:39 -05:00
David Teigland
5e9e43074a lvmetad: rework command connection setup and checking
The lvmetad connection is created within the
init_connections() path during command startup,
rather than via the old lvmetad_active() check.

The old lvmetad_active() checks are replaced
with lvmetad_used() which is a simple check that
tests if the command is using/connected to lvmetad.

The old lvmetad_set_active(cmd, 0) calls, which
stopped the command from using lvmetad (to revert to
disk scanning), are replaced with lvmetad_make_unused(cmd).
2016-04-19 14:00:02 -05:00
David Teigland
2a17610899 lvmetad: disable if command uses lvm1
Alternatively, a command could return an error saying
that lvm1 and lvmetad are not compatible.
2016-04-19 09:41:18 -05:00
David Teigland
04a83148ce lvmetad: use the disabled flag in commands
Commands already check if the lvmetad token is valid,
and if not, they rescan devices to repopulate lvmetad
before running.  Now, in addition to checking the
lvmetad token, they also check if the lvmetad disabled
flag is set.  If so, they do not use the lvmetad cache
and revert to disk scanning.
2016-04-19 09:41:18 -05:00
David Teigland
e41ee70acc toollib: remove unneeded call in process_each_pv
process_each_pv was doing:

1. lvmcache_seed_infos_from_lvmetad()
   sends pv_list request to lvmetad.

2. get_vgnameids()
   sends vg_list request to lvmetad.

3. _get_all_devices()
   first calls lvmcache_seed_infos_from_lvmetad(),
   which is a no-op if it's already been called.

Because get_vgnameids() does not use the information
from lvmcache_seed_infos_from_lvmetad(), it does not
need to be called prior to get_all_devices where
it is actually needed.
2016-04-19 09:40:24 -05:00
Zdenek Kabelac
88c19d5d72 lvchange: improve refresh for merging thin volume
When running lvchange --refresh on merging thin volume,
try to deactivate snapshot thinLV in case it's preventing
startup of merge process.
2016-04-18 23:05:51 +02:00
Zdenek Kabelac
d1c1f60047 debug: use display_lvname 2016-04-18 12:32:56 +02:00
Alasdair G Kergon
f0179fac31 snapshot: Don't deactivate fictional snapshot LV.
Commit 971ab733b7 ("thin: activation of
merging thin snapshot") also added an incorrect deactivation attempt
for non-thin LVs: find_snapshot(lv)->lv is not designed to be
activated and any attempt to deactivate it is incorrect.
2016-04-14 22:32:26 +01:00
Alasdair G Kergon
c68fb55ac1 toollib: Fix misleading message when forking.
Commands like pvscan --background run entirely in the background,
but others fork only for polling.
2016-04-14 17:21:02 +01:00
Peter Rajnoha
3f6e7f90ca refactor: factor out vg/lv/pv handling part from report_for_selection fn
Functionality will be reused by future patches. Also, it makes the code
more readable.
2016-04-14 15:24:36 +02:00
David Teigland
56c68b3476 lvmetad: preemptively check and rescan in commands
Move checking the lvmetad state, and the possible rescan,
out of lvmetad_send() to the start of the command.

Previously, the token mismatch and rescan would occur
within lvmetad_send() for some other request.  Now,
the token mismatch is detected earlier, so the
rescan can be done before the main command is in
progress.  Rescanning deep within the processing of
another command will disturb the lvmcache state of
that other command.

A rescan already exists at the start of the command
for the case where foreign VGs are going to be read.
This same rescan is now also performed when there is
an lvmetad token mismatch (from a changed global_filter).

The commands pvscan/vgscan/lvscan/vgimport are excluded
from this preemptive checking/rescanning for lvmetad
because they want to do rescanning themselves explicitly.

If rescanning devices fails, then lvmetad has not been
correctly repopulated and should not be used, so make
the command revert to not using lvmetad.
2016-04-13 14:05:42 -05:00
Peter Rajnoha
ed0c779bd1 report: remove superfluous SEGSSTATUS report type
We don't have any report field of this type yet. Return this patch into
the play if we really need that. Currenly we always report status
(result of "status" dm ioctl) for an LV as a whole where we choose
segment which represents the LV, not calling status for each possible
segment it contains - we don't need this now so I'm removing it to
not make the code more complex uselessly.
2016-04-08 14:21:47 +02:00
Peter Rajnoha
50866034a2 cleanup: use common init/destroy_processing_handle in _report fn and cleanup error paths 2016-04-08 11:01:19 +02:00
Zdenek Kabelac
097a724bda lvcreate: %FREE -> %PVS
This is hotfix for RHBZ: https://bugzilla.redhat.com/1324537
However already the %FREE is not a good fit and we need something
better. Meanwhile make  -l%PVS work at least as good as %FREE
for thin-pool.

TODO: this needs rework - it should be allocator to do all the size
decisions at one place.
2016-04-07 22:32:08 +02:00
Zdenek Kabelac
0584e85736 lvconvert: show percent with %.2
lvm2 shows percent values with 2 decimal digits elsewhere so use
it consistently also for this output.
2016-04-06 11:31:02 +02:00
Zdenek Kabelac
7daba90fa3 lvconvert: fix error path test
lvremove_single toollib function returns
ECMD_FAILED or ECMD_PROCESSED.
2016-03-14 23:37:42 +01:00
David Teigland
0f10823ec9 pvchange, pvresize: move exported VG check
Allow pvchange and pvresize to process exported VGs,
and have them check for the exported state in their
single function.

Previously, the exported VG state would trigger a
failure in vg_read()/ignore_vg() because the VGs are
being read with READ_FOR_UPDATE.  Because these commands
read all VGs to search for the intended PVs, any
exported VG would trigger a failure, even if it was
not related to the intended PV.
2016-03-10 13:37:42 -06:00
Zdenek Kabelac
9f4451193b lvconvert: update --help
Use  <>  around user entered option parameters to make it visually
different (just like we use Italic style in man page).

TODO:

In the future we should consistently provide such notation and
possibly generate it automagically from some internal data structures.

Preferably for man pages as well so we report actual set of supported
options.
2016-03-10 18:38:54 +01:00
Zdenek Kabelac
00e641ef37 cleanup: display_lvname 2016-03-10 18:38:54 +01:00
Zdenek Kabelac
8507db1924 cleanup: reoder lines 2016-03-10 18:38:54 +01:00
Zdenek Kabelac
70cbd8f1a5 lvconvert: improve vg parameter parsing
Commit abd9618dd8 tried to improve
parsing of vg name from logical path - but still missed couple
corner cases.

This patch further improves the logic and reuses
validate_lvname_param() for parsing of lv_name.

Also explicitly checks for LVM_VG_NAME in the right case.

So now also properly parses cases like:
  'lvconvert --repairt vg/'
and will provide correct error message.
2016-03-10 18:38:53 +01:00
Zdenek Kabelac
569ba79abf lvconvert: uncache handles missing PV
Allow to process with --uncache when some PVs are missing in VG.

So it's now possible to --uncache cached LV if the cache-pool
has missing PV.
2016-03-10 18:38:53 +01:00
David Teigland
6cf1eff46d toollib: always process in use pvs
With the recent conversion of pvcreate/pvremove to the
common toollib processing function, skipping in-use PVs
in _process_pvs_in_vg prevented them from being protected
as intended by the in-use flag.

The processing code for pvcreate/pvremove checks for the
in-use state itself and prevents using an in-use PV.
If a PV is skipped, it looks like an unused device and
is not protected from being used in pvcreate/pvremove.
2016-03-07 14:15:33 -06:00
David Teigland
a8319e62c0 vgscan: add --notifydbus to send a notification
This command option can be used to trigger a D-Bus
notification independent of the usual notifications
that are sent from other commands as an effect of
changes to PV/VG/LV state.  If lvm is not built with
dbus notification support or if notify_dbus is disabled
in the config, this command will exit with an error.
2016-03-07 10:50:45 -06:00
David Teigland
2d5dc6512e dbus: add notification from commands
When a command modifies a PV or VG, or changes the
activation state of an LV, it will send a dbus
notification when the command is finished.  This
can be enabled/disabled with a config setting.
2016-03-07 10:06:09 -06:00
Peter Rajnoha
27245d97e5 lvrename: support renaming historical logical volumes 2016-03-04 11:36:24 +01:00
Peter Rajnoha
b114b4d723 commands: lvdisplay: recognize -H|--history switch 2016-03-04 10:27:45 +01:00
Peter Rajnoha
53b064b9ae commands: lvremove: also process historical LVs 2016-03-03 13:50:59 +01:00
Peter Rajnoha
ccebf3100d conf: add metadata/record_lvs_history configuration setting
The metadata/record_lvs_history is global switch which enables or
disables recording historical LVs in metadata.

If both metadata/record_lvs_history=1 lvm.conf option and
--nohistory command switch is used at the same time, the
--nohistory prevails.
2016-03-03 13:49:15 +01:00
Peter Rajnoha
b1399090cd commands: lvremove: recognize --nohistory option 2016-03-03 13:49:15 +01:00
Peter Rajnoha
9a34de9cb9 cmd: add 'nohistory' option and wire it up in cmd_context
The --nohistory switch will cause historical LVs to not be recorded
in metadata on demand.
2016-03-03 13:49:15 +01:00
Peter Rajnoha
e112f5ce05 commands: lvs: recognize -H|--history switch
When lvs command is used together with the -H|--history switch,
all historical LVs are reported as well.
2016-03-03 13:49:14 +01:00
Peter Rajnoha
2e7a121062 toollib: honour '-H|--history' switch while executing process_each_lv_in_vg
When processing LVs in a VG and when the -H|--history switch is used,
make process_each_lv_in_vg to iterate over historical volumes too.

For each historical LV, we use dummy struct logical_volume instance with
the "this_glv" reference set to a wrapper over proper struct
historical_logical_volume representation. This makes it possible to process
historical LVs just like normal live LVs (though a dummy one without any
segments and all the other fields zeroed and blank) and it also allows
for using all historical LV related information via lv->this_glv->historical
reference.

One can use a simple call to lv_is_historical to make a difference between
live and historical LV in all the code that is called by process_each_* fns.
2016-03-03 13:49:14 +01:00
Peter Rajnoha
f7e0a4cc18 cmd: add '-H|--history' switch and wire it up in cmd_context and processing_handle
This patch adds "include_historical_lvs" field to struct cmd_context to
make it possible for the command to switch between original funcionality
where no historical LVs are processed and functionality where historical
LVs are taken into account (and reported or processed further). The switch
between these modes is done using the '-H|--history' switch on command
line.

The include_historical_lvs state is then passed to process_each_* fns
using the "include_historical_lvs" field within struct processing_handle.
2016-03-03 13:49:14 +01:00
Peter Rajnoha
e573eca554 metadata: add infrastructure to track LV history
Add new structures and new fields in existing structures to support
tracking history of LVs (the LVs which don't exist - the have been
removed already):

  - new "struct historical_logical_volume"
    This structure keeps information specific to historical LVs
    (historical LV is very reduced form of struct logical_volume +
     it contains a few specific fields to track historical LV
     properties like removal time and connections among other LVs).

  - new "struct generic_logical_volume"
    Wrapper for "struct historical_logical_volume" and
    "struct logical_volume" to make it possible to handle volumes
    in uniform way, no matter if it's live or historical one.

  - new "struct glv_list"
    Wrapper for "struct generic_logical_volume" so it can be
    added to a list.

  - new "indirect_glvs" field in "struct logical_volume"
    List that stores references to all indirect users of this LV - this
    interconnects live LV with historical descendant LVs or even live
    descendant LVs.

  - new "indirect_origin" field in "struct lv_segment"
    Reference to indirect origin of this segment - this interconnects
    live LV (segment) with historical ancestor.

  - new "this_glv" field in "struct logical_volume"
    This references an existing generic_logical_volume wrapper for this
    LV, if used. It can be NULL if not needed - which means we're not
    handling historical LVs at all.

  - new "historical_lvs" field in "struct volume group
    List of all historical LVs read from VG metadata.
2016-03-03 11:26:51 +01:00
Zdenek Kabelac
e04a0184cb cleanup: use lv_is_partial
Check for PARTIAL_LV flag in standard way.
2016-03-03 10:17:03 +01:00
Zdenek Kabelac
afae3355f8 cleanup: missplaced .
Remove misplaced '.' after '?'
Drop extra   'stack;'  after log_debug().
2016-03-01 17:20:47 +01:00
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
Zdenek Kabelac
5c29b54d4d cleanup: poll better check for internal errors 2016-02-25 23:30:25 +01:00
Zdenek Kabelac
cdcf4cc794 lvconvert: use lp->repair
Set variable for repair testing.
2016-02-25 23:30:25 +01:00
Zdenek Kabelac
ec8a75a321 lvconvert: use more display_lvname 2016-02-25 23:30:25 +01:00
Zdenek Kabelac
86a651854f lvconvert: simplify handler processing
Easier code for handler init.
Drop release of pool mem - not needed, as command pool get dropped just
later.
2016-02-25 23:30:25 +01:00
Zdenek Kabelac
abd9618dd8 lvconvert: fix vg parameter
Since we want to read env LVM_VG_NAME vg names,
we cannot just check LV names which do contain '/'.

So before the patch commands like:

> lvconvert --repair vg

Before:

Please provide a valid volume group name

After:
Path required for Logical Volume "vg".
Please provide a valid volume group name

> LVM_VG_NAME=vg lvconvert --repair vg

Before:
Please provide a valid volume group name

After:
Can't find LV vg in VG vg
2016-02-25 23:30:24 +01:00
Zdenek Kabelac
a68e601886 lvresize: fix regression with zero size arg
Commit ca878a3426 introduced an issue
that zero sized extesion suddenly started to be accepted and
missed to return error.

Properly check invalid input values for sizes.
2016-02-25 23:29:57 +01: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
66e175702a pvcreate: fix setting uuid arg
Commit 4de6caf5 ("redefine pvcreate structs") left
out setting the "idp" pointer to the "id" arg.
2016-02-25 12:00:53 -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
a9940bd3c9 vgcreate: use the common toollib pv create
Use the new pvcreate_each_device() function from
toollib, previously added for pvcreate, in place
of the old pvcreate_vol().

This also requires shifting the location where the
lock is acquired for the new VG name.  The lock for
the new VG is supposed to be acquired before pvcreate.
This means splitting the vg_lock_newname() out of
vg_create(), and calling vg_lock_newname() directly
before pvcreate, and then calling the remainder of
vg_create() after pvcreate.

The new function vg_lock_and_create() now does
vg_lock_newname() + vg_create(), like the previous
version of vg_create().

The lock on the new VG name is released before the
pvcreate and reacquired after the pvcreate because
pvcreate needs to reset lvmcache, which doesn't work
when locks are held.  An exception could likely be
made for the new VG name lock, which would allow
vgcreate to hold the new VG name lock across the
pvcreate step.
2016-02-25 09:14:09 -06:00
David Teigland
749a7cecf8 vgextend: use the common toollib pv create 2016-02-25 09:14:09 -06:00
David Teigland
6a1c22aadf pvcreate: use the common toollib pv create 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
David Teigland
ff2267012a vgconvert: refactor to avoid pvcreate code
This uses the vg->pv_write_list in place of the
vg->pvs_to_write list, and eliminates the use of
pvcreate_params.  The label remove and zeroing
steps are shifted out of vg_write() to the higher
level like pvcreate will do.
2016-02-25 09:14:09 -06:00
Zdenek Kabelac
a9634e993a coverity: check cmd pointer exists
Since in _report_init() we check few times for cmd != NULL
keep it consistent and Coverity happier.
2016-02-23 21:40:16 +01:00
Zdenek Kabelac
9b92cb2760 coverity: drop unused assignments 2016-02-23 21:40:16 +01:00
Zdenek Kabelac
dbc71dc05e gcc: cleanup some sign warnings
When comparing unsigned with int, the comparision is made
as 'unsigned' type, so make it rather explicit which type
is being compared.
2016-02-23 12:25:25 +01: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
d84a80afb5 backup: backup_restore_vg: register PVs that need writing via vg->pvs_to_write list
The backup_restore_vg is used directly for restoring the VG from backup.
It's also used to do the VG conversions from one metadata format to
another which means vgconvert calls backup_restore_vg too.

When restoring VG from backup, we need to rewrite/write PV headers as
PVs may have been orphans before and now they're becoming part of some
VG - we need to write the PV_EXT_USED flag at least.

When using the backup_restore_vg for vgconvert, we need to write
completely new PV header in different format.

Avoid the special "pv_write" call and handling that was used before
this patch in vgconvert (vgconvert_single function to be more precise)
and reuse existing internal interface to register PV header for writing
(or rewriting) via vg->pvs_to_write list instead like we do it elsewhere
in the code.

This patch also resolves a problem in which PV headers with target
format were written in the vgconvert_single fn as orphans and VG
metadata were added later on - this was a tiny hack actually.
We can't do this now - we need to write the PV as belonging
to a VG because otherwise the PV_EXT_USED flag won't be written
properly (if the PV header is written as orphan, the PV_EXT_USED
is set to 0, of course, even though metadata are attached later).
So this patch removes this tiny inconsistency which was passing
just fine before because we didn't have any relation to the VG
in PV header before. Now we have the PV_EXT_USED flag which says
the "PV is used in some VG".
2016-02-15 12:44:46 +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
Peter Rajnoha
52999133a3 pv: check for the PV_EXT_USED flag and deny pvcreate/pvchange/pvremove/vgcreate on such PV (unless forced)
Make sure we won't use a PV that is already marked as used. Normally,
VG metadata would stop us from doing that, but we can run into a
situation where such metadata is missing because PVs with MDAs
are missing and the PVs left are the ones with 0 MDAs.

(/dev/sda in this example has 0 MDAs and it belongs to a VG,
but other PVs with MDA are missing)

$ pvs -o pv_name,pv_mda_count /dev/sda
  PV         #PMda
  /dev/sda       0

$ pvcreate /dev/sda
  PV '/dev/sda' is marked as belonging to a VG but its metadata is missing.
  Can't initialize PV '/dev/sda' without -ff.

$ pvchange -u /dev/sda
  PV '/dev/sda' is marked as belonging to a VG but its metadata is missing.
  Can't change PV '/dev/sda' without -ff.
  Physical volume /dev/sda not changed
  0 physical volumes changed / 1 physical volume not changed

$ pvremove /dev/sda
  PV '/dev/sda' is marked as belonging to a VG but its metadata is missing.
  (If you are certain you need pvremove, then confirm by using --force twice.)

$ vgcreate vg /dev/sda
  Physical volume '/dev/sda' is marked as belonging to a VG but its metadata is missing.
  Unable to add physical volume '/dev/sda' to volume group 'vg'.
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
5a32d2c1d9 cleanup: drop unneeded assigns 2016-02-11 18:35:07 +01:00
Zdenek Kabelac
740d27f9fe cleanup: rename usepolicies
Switch to ARG name without '_' in the middle (like all others args).
2016-02-11 18:35:06 +01:00