ATM lvm2 does not yet have any smart code around the estimation of 'best fitting' values - it's rather more or less targeting 'minimal' values.

i.e.  slab bit size is made by this code:

#define DM_VDO_BLOCK_SIZE	UINT64_C(8)	// 4KiB in sectors
slabbits = 31 - clz(vtp->slab_size_mb / DM_VDO_BLOCK_SIZE * 512)
(see:  lvm2/lib/metadata/vdo_manip.c _format_vdo_pool_data_lv())

We need to come with some optimal design getting usable:

pool size ->  best-vdo-defaults  we think user should be using.


So when user start to control some of the settings - what is the order on how should they be prioritized  - 
can we come with some algorithm.

Also which settings user do change most - or do we need all of 'lvm.conf' settings
also present as regular 'lvcreate' options:

aka  lvcreate  --slab-size=10m --uds-memory-size=500M....

This BZ is more focused at the accuracy of the setting as it is spelled today.  The default should be 2G slabs, which seems to be reflected in everything I saw in both the configuration files as well as the verbose output of the lvcreate.  The calculation from 2048m in the config to then use as the value for slab-bits is incorrect, and seems to always be two bits off.

Here is the VDO code in the python suite that calculates slab bits:
> https://github.com/dm-vdo/vdo/blob/master/vdo-manager/vdomgmnt/VDOService.py#L1460
>   def _computeSlabBits(self):
>     """Compute the --slab-bits parameter value for the slabSize attribute."""
>     # add some fudge because of imprecision in long arithmetic
>     blocks = self.slabSize.toBlocks()
>     return int(math.log(blocks, 2) + 0.05)

Conversion (in comment #1) was taking (wrongly) the size stored in MB and instead of '* 2048'  was only doing '* 512' so the resulting number was smaller by factor 4 (2 bits shift)

Fixed with this upstream patch:

https://www.redhat.com/archives/lvm-devel/2020-February/msg00043.html


And updated test suite to validate we get expected size in vdoformat (if new vdoformat is installed)

Adding QA ack for 8.3. Still reproducible with lvm2-2.03.08-3.el8.x86_64:


[root@virt-422 ~]# lvcreate --type vdo -L 10G -V 100G --config 'allocation/vdo_slab_size_mb=2048' myvg/vdo_pool
    The VDO volume can address 7 GB in 14 data slabs, each 512 MB.
    It can grow to address at most 4 TB of physical storage in 8192 slabs.
    If a larger maximum size might be needed, use bigger slabs.
  Logical volume "lvol0" created.

[root@virt-422 ~]# lvcreate --type vdo -L 10G -V 100G --config 'allocation/vdo_slab_size_mb=512' myvg5/vdo_pool5
    The VDO volume can address 7 GB in 58 data slabs, each 128 MB.
    It can grow to address at most 1 TB of physical storage in 8192 slabs.
    If a larger maximum size might be needed, use bigger slabs.
  Logical volume "lvol0" created.

[root@virt-422 ~]# lvcreate --type vdo -n myvdolv1 -L 10G -V 100G myvg4/vdo_pool4
    The VDO volume can address 7 GB in 14 data slabs, each 512 MB.                   # default should be 2G
    It can grow to address at most 4 TB of physical storage in 8192 slabs.
    If a larger maximum size might be needed, use bigger slabs.
  Logical volume "myvdolv1" created.

Verified for


packages:
lvm2-2.03.09-2.el8.x86_64

kernel-tools-4.18.0-214.el8.x86_64
vdo-6.2.3.100-14.el8.x86_64
kernel-core-4.18.0-193.el8.x86_64
kernel-modules-4.18.0-193.el8.x86_64
lvm2-libs-2.03.09-2.el8.x86_64
kernel-core-4.18.0-214.el8.x86_64
kernel-modules-4.18.0-214.el8.x86_64
kernel-4.18.0-214.el8.x86_64
kernel-tools-libs-4.18.0-214.el8.x86_64
kernel-4.18.0-193.el8.x86_64
kmod-kvdo-6.2.3.91-73.el8.x86_64


slab sizes:
128MB
default (2G)
16386MB


tests:
lvcreate, verification of lvcreate `-vvv' output for different slab sizes

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-2020:4546