lvm_import_vdo script uses incorrect slab size

[hostalp]

I started testing the lvm_import_vdo script (RHEL 8) and noticed that it probably reports incorrect vdo_slab_size_mb value.

After looking into the script I noticed that it really uses an incorrect input variable there - the same as for vdo_block_map_cache_size_mb:

	vdo_block_map_cache_size_mb = $(get_mb_size_with_unit_ "$vdo_blockMapCacheSize")
	...
	vdo_slab_size_mb = $(get_mb_size_with_unit_ "$vdo_blockMapCacheSize")

I believe that the vdo_slab_size_mb parameter should use the vdo_slabSize variable instead.

The script is wrong even in the master branch - https://github.com/lvmteam/lvm2/blob/master/scripts/lvm_import_vdo.sh#L336 - thus reporting it here.

[zkabelac]

Fixed within this patch: https://listman.redhat.com/archives/lvm-devel/2022-June/024196.html

The issue itself had no impact on the actual 'table' line used for VDO target - since this slab size is ATM used mainly when formatting volume at the beginning - and since it's been already formatted before the conversion - it had no real impact except for being incorrectly stored in metadata. However over the time it might possibly cause problems in the future for some calculation so it's better to have it fixed.

[hostalp]

Maybe I see an old version of the patch, but are you sure that the following change is correct?

-	vdo_slab_size_mb = $(get_mb_size_with_unit_ "$vdo_blockMapCacheSize")
+	vdo_slab_size_mb = $(( $(get_kb_size_with_unit_ "$vdo_blockMapCacheSize") / 1024 ))

It still doesn't appear to use vdo_slabSize there.

[zkabelac]

Right - I must have been completely blind committing version for testing difference without proper merge.
As I've longer set of VDO patched not yet committed - and the real fix for slabSize has been left unmerged yet...

I'll fix this once again.

[zkabelac]

Now with explicit 'diff' change:

https://listman.redhat.com/archives/lvm-devel/2022-July/024227.html