Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
100%
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.
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.
https://access.redhat.com/errata/RHBA-2021:4359