Bug 1636047 - document --indexMem disk footprint
Summary: document --indexMem disk footprint
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: vdo
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Joseph Chapman
QA Contact: Jakub Krysl
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-04 10:45 UTC by Jakub Krysl
Modified: 2019-08-06 13:08 UTC (History)
6 users (show)

Fixed In Version: 6.1.2.16
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-06 13:08:04 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2233 None None None 2019-08-06 13:08:14 UTC

Description Jakub Krysl 2018-10-04 10:45:02 UTC
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:

Comment 2 Jakub Krysl 2018-10-04 10:52:32 UTC
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

Comment 4 Jakub Krysl 2019-04-29 16:14:26 UTC
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?

Comment 5 Jakub Krysl 2019-05-27 11:14:03 UTC
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.

Comment 7 errata-xmlrpc 2019-08-06 13:08:04 UTC
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


Note You need to log in before you can comment on or make changes to this bug.