+++ This bug was initially created as a clone of Bug #2028905 +++
Description of problem:
After the update to 8.5 thin_check with the option
thin_check --super-block-only --clear-needs-check-flag fsild
Version-Release number of selected component (if applicable):
4.18.0-348.2.1.el8_5.x86_64
lvm2-2.03.12-10.el8.x86_64
How reproducible:
all our 8.5 systems
Steps to Reproduce:
1.
set
thin_check_options = [ "-q", "--clear-needs-check-flag", "--super-block-only" ]
in /etc/lvm/lvm.conf in order to speed up boot
2.
reboot system
3.
Actual results:
logical volumes won't get activated
Expected results:
logical voluems become active
Additional info:
running an
vgchange -ay afterwards shows
vgchange -ay VolGroupData
cannot perform fix without a full examination
Usage: thin_check [options] {device|file}
Options:
{-q|--quiet}
{-h|--help}
{-V|--version}
{-m|--metadata-snap}
{--auto-repair}
{--override-mapping-root}
{--clear-needs-check-flag}
{--ignore-non-fatal-errors}
{--skip-mappings}
{--super-block-only}
Check of pool VolGroupData/pool failed (status:1). Manual repair required!
cannot perform fix without a full examination
Usage: thin_check [options] {device|file}
[lvol0_pmspare] VolGroupData ewi------- <15,88g
pool VolGroupData twi---t--- 20,00t
[pool_tdata] VolGroupData Twi------- 20,00t
[pool_tmeta] VolGroupData ewi------- <15,88g
changeing option to
thin_check_options = [ "-q", "--clear-needs-check-flag" ]
lets vgchange -ay succeed without any error
vgchange -ay VolGroupData
examining superblock
TRANSACTION_ID=306
METADATA_FREE_BLOCKS=4162559
examining devices tree
examining mapping tree
checking space map counts
2 logical volume(s) in volume group "VolGroupData" now active
Behavior is reproduceable
I can setup a testsystem in order to debug the problem
Regards
Hansjörg
--- Additional comment from Need Real Name on 2021-12-03 18:55:06 UTC ---
Hi
I have no access to
https://issues.redhat.com/browse/RHELPLAN-104738
Is this an know issue which will be fixed?
Is there any workarround?
regards
hansjörg
--- Additional comment from Ming-Hung Tsai on 2021-12-05 04:59:24 UTC ---
Hi,
It's a rule introduced since device-mapper-persistent-data v0.9.0. To prevent recurring errors (e.g., there're still uncaught errors while the NEED_CHECK flag was cleared, results in an inconsistent metadata), the "--clear-needs-check-flag" is not compatible with "--super-block-only" or "--skip-mappings". To workaround this limitation, set thin_check_options to [ "-q", "--skip-mappings" ] or [ "-q", "--clear-needs-check-flag" ]. The former would be more suitable as you need.
Since the rule introduced some sort of inconvenience, there's already a cosmetic fix upstream, that allows --clear-needs-check together with --super-block-only or --skip-mappings. Please check the commit 1fe8a0dbd for more information (https://github.com/jthornber/thin-provisioning-tools/commit/1fe8a0dbd).
--- Additional comment from Ming-Hung Tsai on 2021-12-07 14:28:03 UTC ---
Below is the backport patch for dmpd v0.9.0 el8 and el9, based on upstream 1fe8a0dbd:
https://github.com/mingnus/thin-provisioning-tools/commit/f4675e3f3
The patch guarantees compatibilities on the command line interface and program behavior. With this patch, thin_check won't clear the NEEDS_CHECK flag only if -m or --override-mapping-root is applied (which are diagnostic options). This checking is done implicitly, without returning an error or showing error messages.
Few test cases are added to verify backward compatibilities:
```
mixing-clear-needs-check-flag
ignore-non-fatal-errors-should-pass .................... pass
skip-mappings-should-pass .............................. pass
super-block-only-should-pass ........................... pass
try-clear-needs-check-flag
fatal-errors-should-keep ............................... pass
ignore-non-fatal-errors-should-clear ................... pass
no-errors-should-clear ................................. pass
skip-mappings-should-clear ............................. pass
super-block-only-should-clear .......................... pass
```
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (new packages: device-mapper-persistent-data), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2022:3973