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.
DescriptionRobert Peterson
2016-06-27 20:11:33 UTC
Description of problem:
When we changed fsck.gfs2 to use less memory (to support larger
file systems) we introduced two serious bugs related to inode
link count. This bug covers the first one.
The first bug is caused because the link incrementing function,
incr_link_count, now checks the wrong inode pointer for the
formal inode number.
Version-Release number of selected component (if applicable):
RHEL7.3 pre-release
How reproducible:
Always
Steps to Reproduce:
1.Restore metadata /home/bob/metadata/gfs2/dirty/intec.fscked.meta.gz
to a device.
2.Run fsck.gfs2 -y on the device
3.Run fsck.gfs2 on the device without -y
Actual results:
The first run looks like it worked okay. The second run says:
Directory entry '47896014544dcc748f3d57a48169d4fb' pointing to block 13493145 (0xcde399) in directory 4260194 (0x410162) has the wrong 'formal' inode number.
The directory entry has 4542826 (0x45516a) but the inode has 4542826 (0x45516a)
Remove the corrupt directory entry? (y/n)
Expected results:
The first run of fsck.gfs2 should fix the problem (return code 1),
and a second run should come up clean with return code 0.
Additional info:
I'm not sure how these slipped through, since I ran my complete
set of metadata on it and it did not flag the error.
I have a working patch for this.
Verified in gfs2-utils-3.1.9-3.el7:
[root@south-16 ~]# gfs2_edit restoremeta intec.fscked.meta.gz /dev/sdb1
No valid file header found. Falling back to old format...
Block size is 4096B
This is gfs2 metadata.
There are 469649399 free blocks on the destination device.
Highest saved block is 34012167 (0x206fc07)
34012168 blocks processed, 1025669 saved (100%)
File intec.fscked.meta.gz restore successful.
[root@south-16 ~]# fsck.gfs2 -y /dev/sdb1 &> /tmp/fsck.out
[root@south-16 ~]# fsck.gfs2 /dev/sdb1
Initializing fsck
Validating resource group index.
Level 1 resource group check: Checking if all rgrp and rindex values are good.
(level 1 passed)
Starting pass1
Reconciling bitmaps.
reconcile_bitmaps completed in 0.574s
pass1 completed in 8m49.070s
Starting pass1b
pass1b completed in 0.000s
Starting pass2
pass2 completed in 9.623s
Starting pass3
pass3 completed in 0.000s
Starting pass4
pass4 completed in 0.176s
Starting check_statfs
check_statfs completed in 0.000s
gfs2_fsck complete
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://rhn.redhat.com/errata/RHBA-2016-2438.html