| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
The code should have been calling [suspend|resume]_lv_origin() rather than
[suspend|resume]_lv.
This addresses bug 807069.
|
| |
|
|
|
|
|
|
| |
The logic for resuming the original and newly split LVs was not properly
done to handle situations where anything but the last device in the array
was split. It did not take into account the possible name collisions that
might occur when the original LV undergoes the shifting and renaming of its
sub-LVs.
|
| | |
|
| | |
|
| |
|
|
| |
Use one style for man pages.
|
| |
|
|
|
|
|
| |
When resizing thin pool - we need to use strip info from _tdata volume.
In future more generic solution will be necessary once we start to support
lvconvert (resize of stacked devices and stay properly aligned).
For now we just allow striped or linear LV so this code will work.
|
| |
|
|
|
|
|
| |
When given lvresize new size - round upward for stripes - unless we use % and
we are at the border of free extents.
This patch is not a complete fix and few more cases will need special care.
|
| |
|
|
|
| |
If specifying size with % and we are reaching number
of free extents - round downward with stripes.
|
| |
|
|
| |
and remove few asigns that are not needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libudev does not provide transactions when querying udev database - once we
get the list of block devices (devices/obtain_device_list_from_udev=1) and
we iterate over the list to get more detailed information about device node
and symlink names used etc., the device could be removed just in between we
get the list and put a query for more info. In this case, libudev returns
NULL value as the device does not exist anymore.
Recently, we've added a warning message to reveal such situations. However,
this could be misleading if the device is not related to the LVM action
we're just processing - the non-related block device could be removed in
parallel and this is not an error but a possible and normal operation.
(N.B. This "missing info" should not happen when devices are related to
the LVM action we're just processing since all such processing should be
synchronized with udev and the udev db must always be in consistent state
after the sync point. But we can't filter this situation out from others,
non-related devices, so we have to lower the message verbosity here for a
general solution.)
|
| |
|
|
| |
in the array was specified for removal. This change addresses that (bz806111).
|
| |
|
|
|
|
|
|
|
|
|
| |
various dmeventd plug-ins into a new function called 'dmeventd_lvm2_command',
but the new function did not strip off the "_mlog" extentions that the
mirror plug-in had been doing. This created bug 794904 - failure to replace
devices in a redundant log.
The test suite did catch this scenario because it performs repair tests (mainly)
through the CLI and not dmeventd. It's also not easy to test because the test
itself will hang if the bug is encountered.
|
| |
|
|
|
|
| |
New functions:
- seg_pvs: Print a list of PVs in a seg_pvs list
- pv_dev_name: print name of a PV
|
| | |
|
| |
|
|
| |
Just some missing checks revealed by Coverity in recent code.
|
| |
|
|
|
|
| |
When vg_read fails, it internally unlocks VG if it's been locked,
so in error path we should skip unlock_vg for this case.
(user would see ugly internal warning)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
devel/~ # lvconvert --splitmirrors 1 -n vg/splitted_one vg/mirrored_one
Internal error: LV name vg/splitted_one has invalid form.
Intermediate VG metadata write failed.
After:
devel/~ # lvconvert --splitmirrors 1 -n vg/splitted_one vg/mirrored_one
Logical volume mirrored_one converted.
devel/~ # lvconvert --splitmirrors 1 -n abc/splitted_one vg/mirrored_one
Please use a single volume group name ("vg" or "abc")
Run `lvconvert --help' for more information.
|
| |
|
|
| |
Just small updates and remove <backtrace> after log_error.
|
| |
|
|
|
|
|
|
|
| |
Add make help target.
Add LVM_TEST_PARALLEL to support parallel runs of tests
Work around the problem the dmsetup table/info may return error
by using dmtable and dminfo function that will use 'should'.
(Error happens when some concurently running process removes table
entry while dmsetup command resolves table entries inside the loop.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Activation on remote node should be tried only if it is masked by tags
locally (like when hosttags enabled, IOW activate_lv_excl_local()
doesn't return error.)
Introduced change caused that lvchange -aey succeeded even if volume was
activated exclusively remotely.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Calling vgscan alone should reuse information from the lvmetad (if running).
The --cache option should initiate direct device scan and update lvmetad
appropriately (if running).
This is mainly for vgscan to behave consistently compared to pvscan.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Pvmove should never try to downgrade exclusive lock
for LVs.
This allows pvmove to work again for exclusive activated LVs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
locally or on more nodes while others are activated exclusively.
Current pvmove code can either use local mirror (for exclusive
activation) or cmirror (for clustered LVs).
Because the whole intenal pvmove LV is just segmented LV containing
segments of several top-level LVs, code cannot properly handle
situation if some segment need to be activated exclusively.
Previously, it wrongly activated exclusive LV on all nodes
(locing code allowed it) but now this is no lnger possible.
If there is exclusively activated LV, pvmove is only
possible if all affected LVs are aslo activated exclusively.
(Note that in non-exclusive mode pvmove still activates LVs
on other nodes during move.)
# lvchange -aly vg_test/lv1
# lvchange -aey vg_test/lv2
# pvmove -i 1 /dev/sdc
Error locking on node bar-01: Device or resource busy
Error locking on node bar-03: Volume is busy on another node
...
Failed to activate lv2
|
| |
|
|
|
|
|
| |
There is no real functional change in this patch except it
avoids checking cluster cmirror module twice.
(Flag used in following patch.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
In this case we should allow to use local mirror, check for cmirror
should apply only for lvconvert/lvcreate.
Introduced in 2.02.86 by removing !(lv->status & ACTIVATE_EXCL).
(Partially workaround, it is minimalistic patch for now.)
|
| |
|
|
| |
There is missing some proper reaction when update fails ?
|
| |
|
|
| |
also in error path
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Code adds better support for monitoring of thin pool devices.
update_pool_lv uses DMEVENTD_MONITOR_IGNORE to not manipulate with monitoring.
vgchange & lvchange are checking real thin pool device for existance
as we are using _tpool real device and visible LV pool device might not
be even active (_tpool is activated implicitely for any thin volume).
monitor_dev_for_events is another _lv_postorder like code it might be worth
to think about reusing it here - for now update the code to properly
monitory thin volume deps.
For unmonitoring add extra code to check the usage of thin pool - in case it's in use
unmonitoring of thin volume is skipped.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Try to avoid start of dmeventd during vgremove if the code has any bug
inside.
|
| |
|
|
| |
(compiled only with special debug define)
|
| | |
|
| |
|
|
|
|
|
| |
Patch https://www.redhat.com/archives/lvm-devel/2012-February/msg00118.html
removed initilization of thin volume monitoring, leaving it only for
thin pool - but missed the code move part for monitoring of thin pools.
Effectively making thin pools not monitorable.
|
| |
|
|
|
| |
Check passed in executable path for dmeventd instead of predefined
compiled in path which is not the thing to be executed.
|
| |
|
|
| |
and check for right exit code from pgrep
|
| |
|
|
|
|
|
|
|
| |
Make the teardown really usable - it will try down to remove all the left
devices even from previous test runs
(the only missing piece is probably proper mdadm teardown)
Add few more local vars
Try to setup PATH and LD_LIBRARY_PATH just once.
Try shorter sleeps.
|
| |
|
|
|
|
|
|
| |
Actually restart was failing for different reason - so pass in proper
location of dmeventd for restart from lvm command and avoid using
the one from /sbin location.
Update pv create test with "" around path.
|
