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.

Bug 1834944

Summary:	Make 'underfull btree node' error non-fatal
Product:	Red Hat Enterprise Linux 7	Reporter:	Zdenek Kabelac <zkabelac>
Component:	device-mapper-persistent-data	Assignee:	Ming-Hung Tsai <mtsai>
Status:	CLOSED ERRATA	QA Contact:	Lin Li <lilin>
Severity:	unspecified	Docs Contact:
Priority:	urgent
Version:	7.8	CC:	agk, asanders, asshriva, heinzm, jbrassow, jholt, jmagrini, lilin, lvm-team, mcsontos, msnitzer, mtsai, njajodia, nkshirsa, rhandlin, thornber, toneata
Target Milestone:	rc	Keywords:	ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	device-mapper-persistent-data-0.8.5-3.el7_9.2	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1868235 (view as bug list)		Environment:
Last Closed:	2020-11-10 13:02:48 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:
Bug Depends On:
Bug Blocks:	1868231, 1868235

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