Bug 1966818 - Converted LVM VDO eventually loses its deduplication index.
Summary: Converted LVM VDO eventually loses its deduplication index.
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: kmod-kvdo
Version: 8.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: beta
: ---
Assignee: Matthew Sakai
QA Contact: Filip Suba
Depends On:
TreeView+ depends on / blocked
Reported: 2021-06-02 00:33 UTC by Matthew Sakai
Modified: 2021-11-10 06:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-11-09 19:28:28 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2021:4359 0 None None None 2021-11-09 19:28:38 UTC

Description Matthew Sakai 2021-06-02 00:33:42 UTC
Description of problem:

After converting a non-lvm VDO to an lvm VDO, after a certain amount of new writes, the index will fail to invalidate the moved chapter when it is supposed to. The amount of data required to trigger this condition depends on the state if the index before conversion.

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1. Create a new non-lvm VDO with a default index. Write ~150G of unique data to it. Then note the data blocks used count in VDO statistics.
2. Convert the VDO to an LVM VDO.
3. Write the same 150G of data to the VDO again (without overwriting).
4. Note the new value for "data blocks used".

Actual results:

At some point in the second write, the message "reap_oldest_chapter failed" should get logged. Also, I believe VDO will note that it is destroying the index and making a new one.

The "data  blocks used" count noted in step 4 will be larger than the one noted in step 1.

Expected results:

Neither VDO nor UDS should log any error messages. The "data blocks used" count in step 4 should be the same as the one in step 1.

Additional info:

I only reproduced this through the index at a low level; I did not reproduce this with an entire VDO. The behavior in the failing case may differ somewhat from what I've described.

Comment 4 Filip Suba 2021-08-02 06:44:28 UTC
Verified with kmod-kvdo-

Comment 7 errata-xmlrpc 2021-11-09 19:28:28 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 (kmod-kvdo 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.


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