+++ 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
```