Bug 1505748
| Summary: | vdo: ERROR - vdoformat: formatVDO failed on '/dev/sdc': VDO Status: Exceeds maximum number of slabs supported | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Jakub Krysl <jkrysl> |
| Component: | vdo | Assignee: | Sweet Tea Dorminy <sweettea> |
| Status: | CLOSED ERRATA | QA Contact: | Filip Suba <fsuba> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.3 | CC: | awalsh, bgurney, dkeefe, limershe, pasik, sweettea, yanwang |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 6.2.2.110 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-28 16:42:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jakub Krysl
2017-10-24 08:34:07 UTC
This might be a duplicate of BZ 1511034, or it might not; the key question is this: will the same error appear if there's enough space for the index, but not enough space for the minimum amount necessary for the VDO backing area? If we set up a logical volume that's large enough to hold a default sized index (2.5 GB), but not large enough to hold a single slab (default size: 2 GB), we see this:
[root@rhel75test-20171023 ~]# pvcreate /dev/sdc
Physical volume "/dev/sdc" successfully created.
[root@rhel75test-20171023 ~]# vgcreate TEST /dev/sdc
Volume group "TEST" successfully created
[root@rhel75test-20171023 ~]# lvcreate -L4G -n backing TEST
Logical volume "backing" created.
[root@rhel75test-20171023 ~]# vdo create --name=test4g --device=/dev/TEST/backing --verbose
Creating VDO test4g
modprobe kvdo
vdoformat --uds-checkpoint-frequency=0 --uds-memory-size=0.25 /dev/TEST/backing
vdo: ERROR - vdoformat: formatVDO failed on '/dev/TEST/backing': VDO Status: Out of space
This is a different error than "Exceeds maximum number of slabs supported". Therefore, this is the same issue as covered in BZ 1511034.
*** This bug has been marked as a duplicate of bug 1511034 *** Bryan, I don't see the connection at all. This bug is about the error message when one has more than 8192 slabs worth of physical space. One can demonstrate this bug by having 5.5T of physical space and requesting 128M slabs. Thank you sweettea for reopening this, I agree this is still reproducible:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 100G 0 disk
# vdo create --name vdo --device /dev/sdb --vdoLogicalSize 10T
Creating VDO vdo
Starting VDO vdo
Starting compression on VDO vdo
VDO instance 5 volume is ready at /dev/mapper/vdo
# vdo create --name vdo2 --device /dev/mapper/vdo --vdoSlabSize 128M
Creating VDO vdo2
vdo: ERROR - vdoformat: formatVDO failed on '/dev/mapper/vdo': VDO Status: Exceeds maximum number of slabs supported
And there is no mention about slab count limit in manpage (or --help):
--vdoSlabSize=megabytes
Specifies the size of the increment by which a VDO is grown. Using a smaller size constrains the total maximum physical size that can be accommodated. Must be a power of two between 128M and
32G. Using a value with a S (sectors), B (bytes), K (kilobytes), M (megabytes), G (gigabytes), T (terabytes), P (petabytes) or E (exabytes) suffix is optional. If no suffix is used, the
value will be interpreted as megabytes. The default is 2G.
Thanks for looking into this again.
Mass migration to Filip. Verified with vdo-6.2.2.117-13.el8.
vdo create --name vdo --device /dev/sdb --vdoLogicalSize 10T
Creating VDO vdo
The VDO volume can address 9 TB in 4655 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.
Starting VDO vdo
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-2020:1782 |