| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
In case the filter strings don't include "/dev/disk", and only
include "pci".
|
|
|
|
|
|
|
|
|
|
|
|
| |
"vgchange -aay --autoactivation event" is called by our udev rule.
When the udev rule runs, symlinks for devices may not all be created
yet. If the regex filter contains symlinks, it won't work correctly.
This command uses devices that already passed through pvscan. Since
pvscan applies the regex filter correctly, this command inherits the
filtering from pvscan and can skip the regex filter itself.
See the previous commit b2d80db12e13
"pvscan: use alternate device names from DEVLINKS to check filter"
|
|
|
|
|
|
|
|
|
|
|
|
| |
pvscan --cache <dev> is called by our udev rule at a time when all
the symlinks for <dev> may not be created yet (by other udev rules.)
The regex filter in lvm.conf may refer to <dev> using a symlink name
that hasn't yet been created, which would cause <dev> to not match
the filter regex. The DEVLINKS env var, set by udev, contains all
the symlink names for <dev> that have been or will be created.
So, we add all these symlink names to dev->aliases, as if we had
found them in /dev. This allows <dev> to be recognized by a regex
filter containing a symlink for <dev>.
|
|
|
|
|
|
| |
If a mounted LV is renamed, then fs resizing utilities will fail,
so detect this condition and fail the command before any changes
are made.
|
|
|
|
|
|
|
|
|
| |
It looks like force was not being used to enable crypt resize,
but rather to force an inconsistency between LV and crypt
sizes, so this is either not needed or force in this case
should have some other meaning.
This reverts commit ed808a9b548ca59221d512bfb7ae581e8367fe50.
|
|
|
|
|
|
| |
This reverts commit 92199ad0b98586182a52e2f8cd82c06336e306f1.
This breaks make rpm.
|
|
|
|
|
|
|
|
| |
Update previous commit
"lvresize: only resize crypt when fs resize is enabled"
to enable crypt resizing when --force is set and --resizefs
is not set. This is because it's been allowed in the past
and people have used it, but it's not a good idea.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|