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 finding problems with fsck.gfs2 and large directories, I turned my attention to what gfs2_convert does in such situations. It also causes problems which fsck.gfs2 ends up segfaulting on.
Version-Release number of selected component (if applicable):
gfs2-utils-3.0.12-23.el6.i686
How reproducible:
Every time
Steps to Reproduce:
1. make gfs file system
2. Create large directory using script from bug 624691 comment #7
3. run gfs2_convert from RHEL6 node
Actual results:
Starting fsck of /dev/wic/bigdir on morph-04
fsck from util-linux-ng 2.17.2
Initializing fsck
Validating Resource Group index.
Level 1 RG check.
(level 1 passed)
Starting pass1
Pass1 complete
Starting pass1b
Pass1b complete
Starting pass1c
^M2 percent complete.^MPass1c complete
Starting pass2
Type 'fifo' in dir entry (a_really_really_long_filename_to_make_very_quick_use_of_tiny_little_dentry_blocks.17917, 44834/0xaf22) conflicts with type 'file' in dinode. (Dir entry is stale.)
Leaf entry count updated
Block 44835 (0xaf23) seems to be free space, but is marked as data in the bitmap.
The bitmap was fixed.
Bad directory entry 'a_really_really_long_filename_to_make_very_quick_use_of_tiny_little_dentry_blocks.17917' cleared.
Leaf 42697 (0xa6c9) entry count in directory 254 (0xfe) doesn't match number of entries found - is 1, found 0
Type 'fifo' in dir entry (a_really_really_long_filename_to_make_very_quick_use_of_tiny_little_dentry_blocks.551, 1597/0x63d) conflicts with type 'file' in dinode. (Dir entry is stale.)
Leaf entry count updated
Block 1598 (0x63e) seems to be free space, but is marked as data in the bitmap.
...
Expected results:
fsck.gfs2 after gfs2_convert should be clean
Additional info:
Created attachment 442908[details]
will_it_convert test log with full fsck.gfs2 output
Here's the test log for the big_directory test case of will_it_convert. morph-01, running RHEL5, creates the GFS file system, creates the big directory, and runs fsck.gfs. morph-04, running RHEL6, runs gfs2_convert and fsck.gfs2.
I was able to recreate the problem on roth-01. I verified that
it is not fixed by the patch for bug #628013. Abhi volunteered
to investigate it, so I'm reassigning.
I'm able to reproduce this. This scenario escaped my testing. gfs2_convert doesn't handle large directories (height >= 2) very well. It seems quite similar to the problem we had with indirect blocks in regular files. The gfs_indirect struct is bigger than gfs2's meta_header struct. This means there are more pointers/block in gfs2 than gfs1. So, a height 2 dir in gfs1 could be a height 1 dir in gfs2. This scenario and other associated conditions need to be fixed correctly. I need to dig through the convert code some more before I can come up with a patch.
Created attachment 451140[details]
First attempt at patch
I've had a bit of luck with this patch... seems to work ok on various height levels at 512b blocks size. I'd like to test this a bit more before checking it in though.
It moves a lot of code around, mainly because two functions (adjust_indirect_blocks) and (adjust_jdata_inode) were doing a lot of the same things and the latter function was too long. Adding support for directory conversion would've added a third function that would duplicate a lot of the same code... so I consolidated the common things into two smaller functions, now called adjust_indirect_blocks() and get_metablocks(). The file-type specific functions are now in two separate functions fix_ind_jdata() and fix_ind_reg_or_dir().
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
http://rhn.redhat.com/errata/RHBA-2011-0537.html