Bug 2108254

Two more "use_*" properties that don't work. "Unknown VDO setting", the user needs to drop "use_" in order to actually use these properties.

# use_metadata_hints

[root@hayes-01 ~]# lvconvert --yes --type vdo-pool -n vdo_lv --vdosettings vdo_use_metadata_hints=1 -V100G vdo_sanity/vdo_pool
  Unknown VDO setting "vdo_use_metadata_hints".

[root@hayes-01 ~]# lvconvert --yes --type vdo-pool -n vdo_lv --vdosettings vdo_metadata_hints=1 -V100G vdo_sanity/vdo_pool
  WARNING: Converting logical volume vdo_sanity/vdo_pool to VDO pool volume with formating.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
    The VDO volume can address 6 GB in 3 data slabs, each 2 GB.
    It can grow to address at most 16 TB of physical storage in 8192 slabs.
    If a larger maximum size might be needed, use bigger slabs.
  Logical volume "vdo_lv" created.
  Converted vdo_sanity/vdo_pool to VDO pool volume and created virtual vdo_sanity/vdo_lv VDO volume.


# use_sparse_index
[root@hayes-01 ~]# lvconvert --yes --type vdo-pool -n vdo_lv --vdosettings 'vdo_use_sparse_index=1' -V100G vdo_sanity/vdo_pool
  Unknown VDO setting "vdo_use_sparse_index".

[root@hayes-01 ~]# lvconvert --yes --type vdo-pool -n vdo_lv --vdosettings 'vdo_sparse_index=1' -V100G vdo_sanity/vdo_pool
  WARNING: Converting logical volume vdo_sanity/vdo_pool to VDO pool volume with formating.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Minimum required size for VDO volume: 26130157568 bytes
vdoformat: formatVDO failed on '/dev/vdo_sanity/vdo_pool': VDO Status: Out of space
  Command /usr/bin/vdoformat failed.
  Cannot format VDO pool volume vdo_sanity/vdo_pool.

[root@hayes-01 ~]# lvconvert --yes --type vdo-pool -n vdo_lv --vdosettings 'vdo_sparse_index=26130157568' -V100G vdo_sanity/vdo_pool
  WARNING: Converting logical volume vdo_sanity/vdo_pool to VDO pool volume with formating.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Minimum required size for VDO volume: 26130157568 bytes
vdoformat: formatVDO failed on '/dev/vdo_sanity/vdo_pool': VDO Status: Out of space
  Command /usr/bin/vdoformat failed.
  Cannot format VDO pool volume vdo_sanity/vdo_pool.

I filed https://bugzilla.redhat.com/show_bug.cgi?id=2108326 for the use_sparse_index issue.

Same patch fixing  vdo_use_sparse_index is  also a working fix for  vdo_use_compression

https://listman.redhat.com/archives/lvm-devel/2022-August/024268.html

Of the 6 scenarios in the initial bug report (vdo_use_compression, use_compression, vdo_compression X set, display), 3 of them worked. Now with the fix, of those 6, 4 work. Without the requested devel test results, I'm not sure which of these are supposed to work and which are not, so moving this back to ASSIGNED. 

The lvmvdo(7) page mentions only vdo_use_compression
   4. Change the default settings used for creating a VDOPoolLV
      [...]
          allocation {
              vdo_use_compression=1

However the lvs stderr mentions only vdo_compression
From lvs stderr:
    vdo_compression             - Set for compressed LV (vdopool).

Instead of attempting to support three different variables for the same thing, and documenting just two of them, why don't we just pick one, and document and allow just that one for displaying and setting?


kernel-4.18.0-442.el8.v2    BUILT: Mon Dec  5 14:06:21 CST 2022
lvm2-2.03.14-9.el8    BUILT: Thu Dec  8 10:40:55 CST 2022
lvm2-libs-2.03.14-9.el8    BUILT: Thu Dec  8 10:40:55 CST 2022


[root@hayes-01 ~]# lvs -a -o +devices
  LV               VG         Attr       LSize   Pool     Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices          
  vdo_lv           vdo_sanity vwi---v--- 100.00g vdo_pool                                                vdo_pool(0)      
  vdo_pool         vdo_sanity dwi-------  10.00g                                                         vdo_pool_vdata(0)
  [vdo_pool_vdata] vdo_sanity Dwi-------  10.00g                                                         /dev/sdf1(0)     

                
# vdo_use_compression (set) - PASS
[root@hayes-01 ~]# lvchange --vdosettings 'vdo_use_compression = 1' vdo_sanity/vdo_pool
  Logical volume vdo_sanity/vdo_pool changed.
# vdo_use_compression (display) - FAIL
[root@hayes-01 ~]# lvs  -o vdo_use_compression vdo_sanity/vdo_lv
   [...]
  Unrecognised field: vdo_use_compression


# use_compression (set) - PASS
[root@hayes-01 ~]# lvchange --vdosettings 'use_compression = 0' vdo_sanity/vdo_pool
  Logical volume vdo_sanity/vdo_pool changed.
# use_compression (display) - FAIL
[root@hayes-01 ~]# lvs  -o use_compression vdo_sanity/vdo_lv
   [...]
  Unrecognised field: use_compression


# vdo_compression (display) - PASS
[root@hayes-01 ~]# lvs  -o vdo_compression vdo_sanity/vdo_lv
  VDOCompression
         enabled
# vdo_compression (set) - PASS
[root@hayes-01 ~]# lvchange --vdosettings 'vdo_compression = 0' vdo_sanity/vdo_pool
  Logical volume vdo_sanity/vdo_pool changed.
[root@hayes-01 ~]# lvs  -o vdo_compression vdo_sanity/vdo_lv
  VDOCompression

What was tested  in  comment 7  is well in line with the coded state
Failure of lvs with vdo_use_compression is OK - since property was originally named   'vdo_compression' as 'status of compression' while 'vdo_use_compression' is a 'setup directive' on creation time.

There was not yet made any further progress on making also 'lvs' reporting somewhat more forging and requires to use proper full name to obtain the value.

My original idea of adding more 'settings' as aliases makes listing of  'lvs -o help' really long and even way more confusing than it already is.

My next idea is to implement aliasing as a feature of individual property - but that's currently just an idea - but I can see a slight confusion in user's eye - so eventually we will deal with this issue in some way to simplify it.

But ATM --vdosettting (since it knows it relates to vdo properties) is just smarter version for setting values - but they could be equally well setting though --config or --profile setting - but there you have to use full names.

Marking this partial fix Verified:Tested per the instructions of comment #7.

Any further fixes for this incomplete feature will require additional bugzillas opened with clear instructions about expectations for QA.

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 (lvm2 bug fix and enhancement update), 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-2023:3048