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.
Bug 1834944 - Make 'underfull btree node' error non-fatal
Summary: Make 'underfull btree node' error non-fatal
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: device-mapper-persistent-data
Version: 7.8
Hardware: Unspecified
OS: Unspecified
urgent
unspecified
Target Milestone: rc
: ---
Assignee: Ming-Hung Tsai
QA Contact: Lin Li
URL:
Whiteboard:
: 1775371 (view as bug list)
Depends On:
Blocks: 1868231 1868235
TreeView+ depends on / blocked
 
Reported: 2020-05-12 17:55 UTC by Zdenek Kabelac
Modified: 2024-03-25 15:55 UTC (History)
17 users (show)

Fixed In Version: device-mapper-persistent-data-0.8.5-3.el7_9.2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1868235 (view as bug list)
Environment:
Last Closed: 2020-11-10 13:02:48 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:5016 0 None None None 2020-11-10 13:02:56 UTC

Description Zdenek Kabelac 2020-05-12 17:55:39 UTC 
Description of problem:

Implement new extension to thin_check to handle automatic fixing of simple
thin pool metadata corruptions/leaks (in similar way we handle --clear-needs-check-flag.

Possible new name of an option could be '--fix-metadata-leaks'.

This would allow (if user wants) to enable such fixing through automatic
call of thin_check  with thin-pool activation.

Version-Release number of selected component (if applicable):
2.02.188
Comment 2 Joe Thornber 2020-05-13 06:35:26 UTC 
If the machine crashes, or the admin takes it down without doing a clean shutdown of dm-thin (looking at you Docker), then it's possible for a small number of metadata blocks to be leaked.  This means they are marked as allocated when in fact they're not used.  This potential leak was a deliberate design choice; we gain performance by allowing it, and it's harmless to user data.

The proposal here is:

*if* there are no other issues with the metadata, and the --fix-metadata-leaks flag is set.  Then knock the
incorrect reference counts back to 0.  This can be done in place by adjusting the space map bitset page.  By doing this in place we avoid allocating a new metadata area and rebuilding all the metadata.

If the leaked metadata block has a count higher than 2 (not sure this is possible), then the count will be
stored in the overflow btree.  In this case --fix-metadata-leaks should do nothing, and thin_check should fail.
Comment 14 Jonathan Earl Brassow 2020-08-12 05:11:34 UTC 
This bug has been split into two parts:

PART 1: Bug 1834944 will now only address the need to designate 'underfull btree nodes' as a non-fatal error.  Currently, the 'metadata leak' error is already non-fatal.  Thus, with the underfull fix and by setting '--ignore-non-fatal-errors' as a thin_check option in lvm.conf, customers will be able to boot and activate their systems without being forced to run a repair

PART 2: Bug 1868231 will address the desire to have thin_check automatically repair these non-fatal errors during the check process - cleansing the metadata, if desired.  This step is unnecessary for correct operation of thin-p and is thus considered low priority; but may accompany another fix (e.g. Bug 1490517).
Comment 16 Jonathan Earl Brassow 2020-08-17 18:57:42 UTC 
stripping rhel7.7.z requirement.
Comment 17 Jonathan Earl Brassow 2020-09-09 13:47:53 UTC 
*** Bug 1775371 has been marked as a duplicate of this bug. ***
Comment 23 Ming-Hung Tsai 2020-09-22 16:01:48 UTC 
The target release was decided to be 7.9.z
Comment 38 errata-xmlrpc 2020-11-10 13:02:48 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 (device-mapper-persistent-data 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-2020:5016
Note You need to log in before you can comment on or make changes to this bug.