Hide Forgot
Description of problem: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 10G 0 disk # vdo create --device='/dev/sdb' --vdoSlabSize='2G' --name='vdo_test' --indexMem='1' Creating VDO vdo_test vdo: ERROR - vdoformat: formatVDO failed on '/dev/disk/by-id/scsi-360fff19aad198f7e32a79578cd06903b': VDO Status: Out of space # vdo create --device='/dev/sdb' --vdoSlabSize='2G' --name='vdo_test' Creating VDO vdo_test Starting VDO vdo_test Starting compression on VDO vdo_test VDO instance 7 volume is ready at /dev/mapper/vdo_test There is no indication in manpage why increasing --indexMem should cause disk OOS: # man vdo --indexMem=gigabytes Specifies the amount of index memory in gigabytes; the default is currently 0.25 GB. The special decimal values 0.25, 0.5, 0.75 can be used, as can any integer value at least 1 and less than or equal to 1024. (The special decimal values are matched as exact strings; "0.5" works but "0.50" is not accepted.) Version-Release number of selected component (if applicable): vdo-6.1.1.125-3.el7 How reproducible: 100% Steps to Reproduce: 1. vdo create --device='/dev/sdb' --vdoSlabSize='2G' --name='vdo_test' --indexMem='1' 2. man vdo Actual results: no mention of increasing --indexMem could lead to disk OOS in manpage Expected results: Description in manpage that this could happen Additional info:
The same issues is with --sparseIndex, changing ticket accordingly as the issue is too similar to create new ticket. # vdo create --device='/dev/sdb' --name='vdo_test' --sparseIndex='enabled' Creating VDO vdo_test vdo: ERROR - vdoformat: formatVDO failed on '/dev/disk/by-id/scsi-360fff19aad198f7e32a79578cd06903b': VDO Status: Out of space # vdo create --device='/dev/sdb' --name='vdo_test' Creating VDO vdo_test Starting VDO vdo_test Starting compression on VDO vdo_test VDO instance 8 volume is ready at /dev/mapper/vdo_test
vdo-6.1.2.41-4.el7.x86_64 man vdo: --indexMem=gigabytes Specifies the amount of index memory in gigabytes; the default is currently 0.25 GB. The special decimal values 0.25, 0.5, 0.75 can be used, as can any integer value at least 1 and less than or equal to 1024. (The special decimal values are matched as exact strings; "0.5" works but "0.50" is not accepted.) Larger values will require more disk space. For a dense index, each gigabyte of index memory will use approximately 11 GB of storage. For a sparse index, each gigabyte of index memory will use approximately 100 GB of storage. So the original issue is fixed, --indexMem disk footprint is documented. But #c2 seems to have been missed, --sparseIndex seems to have no change. --sparseIndex={ enabled | disabled } Enables sparse indexing. The default is disabled. Should I create new BZ to address the missing --sparseIndex disk footprint docs?
At this stage it seems better to have new ticket for the --sparseIndex issue (BZ 1714198). Closing this BZ as --indexMem is fixed and returning the subject to original state.
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, 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-2019:2233