Description of problem: When caching an LV - the table line for such LV might be incorrectly generated. This however happen only when user supplies some extra cache setting - which in case of SMQ policy is only 'migration_threshold' which has got explicit handling. The lvm2 used this incorrect evaluation to get number of args for caching target as discovered here: https://github.com/lvmteam/lvm2/issues/55 Version-Release number of selected component (if applicable): 2.03.13 Steps to Reproduce: 1. lvcreate -L10 -n lv vg 2. lvcreate -H -L10 vg/lvol0 --cachepolicy mq --cachesettings 'read_promote_adjustment=10 migration_threshold=4096' Checking the table give 4 args to target: metadata2 writethrough mq 4 migration_threshold 4096 read_promote_adjustment 10 ^^^ Additional info: Majority of users actually never uses any --cachesettings - and default SMQ accepts only migration_threshold - so the bug was basically unnoticeable.
Solved upstream this way: Avoids supplying unsupported cache settings from MQ & SMQ cache policies which avoid hitting unpleasant suspend errors: https://listman.redhat.com/archives/lvm-devel/2021-September/msg00015.html Enhance revert path when cache table load fails on lvcreate: https://listman.redhat.com/archives/lvm-devel/2021-September/msg00019.html Fix actual parentheses errors: https://listman.redhat.com/archives/lvm-devel/2021-September/msg00035.html