| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
The filter may contains a symlink for the device, and that symlink
may not yet be created when our udev rule runs pvscan --cache using
the kernel dev name. The kernel dev name does not match the symlink
name in the filter, so pvscan will ignore the device. udev sets
the DEVLINKS env variable to a list of link names for the device
that will be created, so check the filter with that set of names.
|
|
|
|
|
|
|
|
|
|
|
| |
There were a couple of cases where lvresize, without --fs resize,
was resizing the crypt layer above the LV. Resizing the crypt
layer should only be done when fs resizing is enabled (even if the
fs is already small enough due to being independently reduced.)
Also, check the size of the crypt device to see if it's already
been reduced independently, and skip the cryptsetup resize if
it's not needed.
|
|
|
|
| |
Remove unnecessary '\'.
|
|
|
|
|
|
| |
While the output of building looks more polished, text editors fail to
find source file from compile errors - so until we start to print
all file with full paths - comment out this make build parameter.
|
|
|
|
| |
Fix building without ioctl support.
|
| |
|
|
|
|
|
| |
ATM kernel VDO target does not handle resize of inactive VDO LVs
so prevent users corrupting such LVs and require active such LVs.
|
|
|
|
|
|
|
|
| |
Enhance checking vdo constains so it also handles changes of active VDO LVs
where only added difference is considered now.
For this also the reported informational message about used memory
was improved to only list consuming RAM blocks.
|
|
|
|
|
|
|
|
| |
Introduce struct vdo_pool_size_config usable to calculate necessary
memory size for active VDO volume.
Function lv_vdo_pool_size_config() is able to read out this
configuration out of runtime DM table line.
|
|
|
|
|
| |
When we are actually resizing VDO device - we need to check size only in
non-critical section - otherwise we are checking
|
|
|
|
|
| |
We need to validate whether the requested resizing size can be
expressed with given extent_size.
|
|
|
|
|
| |
Signed-off-by: lilinjie <lilinjie@uniontech.com>
(cherry picked from commit 81b1f5bc3bac0e2e9099b67162da7d1a4995c5f4)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cover a case missed by the recent commit e0ea0706d
"report: query lvmlockd for lv_active_exclusively"
Fix the lv_active_exclusively value reported for thin LVs.
It's the thin pool that is locked in lvmlockd, and the thin
LV state was mistakenly being queried and not found.
Certain LV types like thin can only be activated exclusively, so
always report lv_active_exclusively true for these when active.
|
| |
|
|
|
|
|
|
| |
If one of the PVs in the VG does not hold metadata, then the
command would fail, thinking that PV was from a different VG.
Also add missing free on that error path.
|
| |
|
|
|
|
|
|
|
|
| |
typo used "cryptresize" as command name
this affects cases where the file system is resized
independently, and then the lvresize command is used
which only needs to resize the crypt device and the LV.
|
|
|
|
| |
Typos found with codespell.
|
| |
|
| |
|
| |
|
|
|
|
| |
Fix memleak in function.
|
|
|
|
| |
Some for y38k - calculations can handle 64b time_t.
|
|
|
|
| |
Count with extra 1 byte for buffer end '\0'.
|
| |
|
|
|
|
| |
Nothing to be closed on this error path.
|
|
|
|
|
|
|
|
| |
18722dfdf4d3 lvresize: restructure code
mistakenly changed the overprovisioning check from applying
to all lv_is_thin_type lvs to only lv_is_thin_pool lvs, so
it no longer applied when extending thin lvs. The result
was missing warning messages when extending thin lvs.
|
|
|
|
| |
Two new settings for tuning dm-writecache.
|
|
|
|
| |
It was being ignored.
|
|
|
|
|
|
|
| |
The recent change that verifies sys_serial system.devices entries
using the PVID did not exclude non-PV devices from being checked.
The verification code would attempt to use du->pvid which was null
for the non-PVs causing a segfault.
|
|
|
|
| |
for covscan
|
|
|
|
| |
on malloc failure path
|
|
|
|
| |
for covscan
|
| |
|
|
|
|
|
| |
in get_local_nodeid from recent lock purge feature:
lvmlockd: purge the lock resources left in previous lockspace
|
|
|
|
| |
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2145114
|
|
|
|
| |
Moving this so we can re-use outside of lvm_shell_proxy.
|
|
|
|
| |
Recreates https://bugzilla.redhat.com/show_bug.cgi?id=2145114
|
|
|
|
| |
Use <name> consistenly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With newer kernels (>5.13) DM_CREATE no longer generates
uevent for DM devices without table.
There are even no sysfs block device entries in such case,
although device has asigned major:minor and it is being listed
by 'dmsetup info'.
So this patch calculates amount of 'table' lines and in case
no table line comes from cmdline or stdin - waiting on cookie
is avoided generically instead of disabling just case with
option --notable - which then also skipped handling of an
option --addnodeoncreate (which is however historical and
should be avoided)
As a result there should be no leaking udev cookies and endlessly
waiting commands like this:
dmsetup create mytestdev </dev/null
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We can't assume that strerror_r returns char* just because _GNU_SOURCE is
defined. We already call the appropriate autoconf test, so let's use its
result (STRERROR_R_CHAR_P).
Note that in configure, _GNU_SOURCE is always set, but we add a defined
guard just in case for futureproofing.
Bug: https://bugs.gentoo.org/869404
|
|
|
|
|
|
|
| |
This allows users to use e.g. `llvm-readelf`
on systems with binutils as default.
Bug: https://bugs.gentoo.org/840628
|
| |
|
|
|
|
|
|
|
|
| |
Query LV lock state in lvmlockd to report lv_active_exclusively
for active LVs in a shared VGs. As with all lvmlockd state,
it is from the perspective of the local node.
Signed-off-by: corubba <corubba@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
| |
Add a note to the manpage that lvmlockd is unable to determine
accurately and without side-effects whether a LV is remotely active.
Also change the value of the lv_active_remotely option from false to
undefined for shared VGs to distinctly communicate that inability to
users. Only for local VGs it can be definitely stated that they are not
remotely active.
Signed-off-by: corubba <corubba@gmx.de>
|
| |
|
| |
|
| |
|