IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Revert 373372c8ab3749bc76ced37cec04b00aae6e5979 and instead update
our validation code to handle LVs with empty segment - currently
we should need this only for pvmove operation, thus such LV should
have name 'pvmove%u'.
This fixes a problem where user tried i.e. pvmove on a VG with single
PV - as reported: https://github.com/lvmteam/lvm2/issues/148
Reported-by: bob@redhat.com
(cherry picked from commit 07b6174f7cb3ac70df2791d54f654d6d5ca36169)
When exit on file is present in a system and term/break signal is
catched, them dmeventd is no longger refusing to exit.
For the correct shutdown, there should be ideally unmonitoring call,
however in some case it's very hard to implement this correct procedure.
With this 'exit on' file dmeventd at least avoid 'blocking' shutdown,
before systemd kills use with -9 anyway possibly even in some unwanted
stated of internal dmeventd processing (i.e. in the middle of some lvm
command processing).
(cherry picked from commit a9d7a9d1289d7cafa1db5fd1e41417bf4f7709d1)
To quickly get info about some internal dmeventd status,
implment 'dmeventd -i' support.
Reported messages are some 'raw' internal informations mainly
useful to developers.
(cherry picked from commit 80d34abf4974e45471f947fb2b85146a30feb87d)
Instead of just exiting in the middle of monitoring,
unregisted all monitored devices first and then exit.
To speedup this path, all send internal SIGINT when thread
unregiters itself, to wakup-up main sleeping loop.
(cherry picked from commit 637d812df56440d792ab403f63e50583d78cdfef)
It should not change the actual code flow, however make the
set of the current_event variable inside locked section.
(cherry picked from commit 29630b2d7fcb28827f0c928edd6cd638f6ea2591)
The approach to duplicate VGIDs has been that it is not possible
or not allowed, so the behavior has been undefined. The actual
result was unpredictable and/or broken, and generally unhelpful.
Improve this by recognizing the problem, displaying the VGs,
and printing a warning to fix the problem. Beyond this,
using VGs with duplicate VGIDs remains undefined, but should
work well enough to correct the problem with vgchange -u.
It's possible to create this condition without too much difficulty
by cloning PVs, followed by an incomplete attempt at making the two
VGs unique (vgrename and pvchange -u, but missing vgchange -u.)
(cherry picked from commit 18f451e09e943eb3d51f8394f6fe8967e1e9f565)
After a vg_write, this function was used to attempt to
make lvmcache data match the new state written to disk.
It was not updated correctly in a many or most cases,
and the resulting lvmcache is not actually used after
vg_write, making the update unnecessary.
(cherry picked from commit cb798ee1c102aadde93965a894c5aa59d4e76e4a)
The destination vg is first written with the EXPORTED flag,
then the source vg is written, then the destination vg is
written again without the EXPORTED flag. Remove an unnecessary
vg_read of the destination vg just before the second write.
(cherry picked from commit 5e428d22d9647a294eba65852078947df5ade48f)
If a RaidLV mapping is required to be refreshed as a result of temporarily failed
and recurred RAID leg device (pairs) caused by writes to the LV during failure,
the requirement is reported by volume health character r' in position 9 of the
LV's attribute field (see 'man lvs' about additional volume health characters).
As this character can be overlooked, this patch adds messages to the top
of the lvs command output informing the user explicitely about the fact.
(cherry picked from commit b69f73b13ee55ef3feb7427c6dc099dc3472d9fc)
In case of e.g. 3 PVs, creating or extending a RaidLV causes SubLV
collocation thus putting segments of diffent rimage (and potentially
larger rmeta) SubLVs onto the same PV. For redundant RaidLVs this'll
compromise redundancy. Fix by detecting such bogus allocation on
lvcreate/lvextend and reject the request.
(cherry picked from commit 05c2b10c5d0a99993430ffbcef684a099ba810ad)
With commit d7e922480e04ecfb7c4d8b2d42533699ddef5c34
lvconvert -m may fail if we try to remove 1st. leg that
is out-of-sync while other leg is in-sync.
Hot fix allows to proceed with such down conversion.
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
(cherry picked from commit e41da923a3bec2df603b54f0f466e9574b6544db)
Bail out in case first rimage is out-of-sync.
Refresh first, i.e. "lvchange --resync $RaidLV",
then retry downgrade to linear after resynchronization.
(cherry picked from commit d7e922480e04ecfb7c4d8b2d42533699ddef5c34)
Output from vdo manager may actually indent output with spaces,
so trim leading and ending space.
Also add support for verbosity flag for vdo conversion tool.
(cherry picked from commit 8b75bbe47d2a2961b0fb029ad7a01dc37ee6a8e5)
This vdo parameter existed in the early stage of integration of vdo into lvm2,
but later it's been removed from vdoformat tool - so actually if
there would be any non-zero value it would cause error on lvcreate.
Option was not stored on disk in lvm2 metadata.
Remove this vdo parameter from lvm2 sources.
(Although this vdo parameter will be still accepted on cmdline through
--vdosettings option, but it will be ignored.)
(cherry picked from commit 6ff65e675582265a673136f1edd5358b26c9e481)
lvm_import_vdo will adjust the virtual size within conversion
so the volume can be use without any futher tweaking.
(cherry picked from commit 8d09124c6204d49f6bda833229c96e8a76665127)
Ensure the volume after conversion has the properly aligned size to the
volume group extent size. This would be visible when using virtual size,
that cannot be divided by extent size.
Before the user had to manually adjust the size after conversion to get
access to all data stored on VDO volume.
(cherry picked from commit 657dde6208ddc8172b7d0e1466751046c8ddaeaa)
Since now we change deduplication with V4 table line change,
the modification tends to be faster and we can capture for a few ms
also 'status' about opening or closing deduplication index.
Use 'grep -E' to handle both words.
(cherry picked from commit 0fed9b097120648301faa586970a47b8b4d629ff)
Support size specification in KiB units.
Add some theoretical support for some new options from vdoprepareforlvm.
(cherry picked from commit 7f661a24c4f7fa8f161f17da093e456f0d60e106)
Add support for usage of 'dm-snapshot' for doing whole device conversion
in a snapshot which could be merged once the whole conversion has been
made.
This helps with cases where there would be any unexpected failure in the
middle of conversion process and user can continue using original
device until problem in conversion is fixed.
Import tool now uses 'truncate' tool to create a small backend file (20M) for loop device
to hold COW exception store.
Option --vdo-config has been added to allow specifing location of vdo
configuration file.
Option --no-snapshot allows to use import tool without creation of
snapshot, however recovery after finished VDO conversion and unfinished
lvm2 conversion is then very difficult.
Option --uuid-prefix allow to specify DM UUID prefix for snapshot
device.
Use read with -r.
(cherry picked from commit be6c34212b05d8c59c0ba68e26c56cddf61c9f04)
Improve metadata parser to handle volume_geometry bio_offset,
which needs to be substracted from 'region' start_block when present.
This bio_offset block is non-zero i.e. with converted VDO volumes.
Also fix some converted structure value (but they are not in use).
(cherry picked from commit 00633f8b668d94a58756d96f5927fd690b8f41d3)
Instead of using size of 'empty header' in vdopool use fixed size 4K
for a 'wrappeing' vdo-pool device.
This fixes the issue when user tried to activate vdo-pool after
a conversion from vdo managed device with 'vgchange -ay' - where
this command activated all LVs with 'vdo-pool' wrapping device as well,
but this converted pool uses 0-length header.
This 4k size should usually prevent other tools like 'blkid' recognize
such device as anything - so it shouldn't cause any problems with
duplicate indentification of devices.
(cherry picked from commit e8e6347ba3f59cbd2f7e92aa707543b90fa607a3)
ATM kernel VDO target does not handle resize of inactive VDO LVs
so prevent users corrupting such LVs and require active such LVs.
(manually backported from commit c20f01a0cbb24e8276734a00f26a510cf6daaf21)
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.
(cherry picked from commit 2451bc568feb9b3d0cb4d7c15e3c723f4d0c8cc9)
Return failing error code for return path, as 'return 0' in this
case was returning success.
(cherry picked from commit b9f35e07db41f3dd6bea2c91a8bc1bff93a4d406)
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.
(cherry picked from commit 1bed2cafe83096cf01cfff5cd2cd64ecb32b7d78)
When we are actually resizing VDO device - we need to check size only in
non-critical section - otherwise we are checking
(cherry picked from commit 773b88e028ab2965a8c185f5f2147334f8f2bbfd)
