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 1186515

Summary: GFS2: fsck.gfs2 fixes good directory goal value
Product: Red Hat Enterprise Linux 7 Reporter: Nate Straz <nstraz>
Component: gfs2-utilsAssignee: Abhijith Das <adas>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: high    
Version: 7.1CC: adas, cluster-maint, gfs2-maint, sbradley, swhiteho
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gfs2-utils-3.1.8-2.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1201786 1238754 (view as bug list) Environment:
Last Closed: 2015-11-19 03:53:31 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: 1184482    
Bug Blocks: 1201786, 1205796, 1238754    
Attachments:
Description Flags
make check_i_goal skip dirs whose goal blocks are not zero
none
another patch that attempts to do more of the right thing
none
make check_i_goal skip dirs whose goal blocks are out of fs bounds none

Description Nate Straz 2015-01-27 20:32:52 UTC
Description of problem:

After running d_io on a cluster and running fsck.gfs2 on the file system I found that fsck.gfs2 often produces an error message like this:

Error: inode 99591 (0x18507) has invalid allocation goal block 204891 (0x3205b). Should be 99591 (0x18507)

On further inspection, block 204891 is actually a directory leaf block of inode 99591.

[root@host-051 tmp]# gfs2_edit -p 204891 /dev/STSRHTS16693/STSRHTS166930
Block #204891    (0x3205b) of 1308672 (0x13f800) (directory leaf)

Leaf:
  mh_magic              0x01161970(hex)
  mh_type               6                   0x6
  mh_format             600                 0x258
  lf_depth              5                   0x5
  lf_entries            14                  0xe
  lf_dirent_format      1200                0x4b0
  lf_next               0                   0x0
  lf_inode              99591               0x18507
  lf_dist               1                   0x1
  lf_nsec               668537594           0x27d912fa
  lf_sec                1422389987          0x54c7f2e3

This probably doesn't need to be fixed

Version-Release number of selected component (if applicable):
gfs2-utils-3.1.7-6.el7.x86_64

How reproducible:
Easily

Steps to Reproduce:
1. run d_io -S QUICK on a GFS2 file system
2. fsck.gfs2


Actual results:


Expected results:


Additional info:

Comment 2 Abhijith Das 2015-01-28 16:41:38 UTC
fsck.gfs2 doesn't traverse the metadata tree for dirs in pass1 to be able to get at the last allocated block for it and attempts to set it to the inode block itself when it finds the i_goal value to be outside of the current rgrp. This is not desirable and fsck.gfs2 should probably leave directories alone.

Nate also reported that gfs2_convert isn't making an attempt to fix goal values either and results in zeros being set instead. The fix for that needs to be rolled in along with this bug's patch.

Comment 3 Abhijith Das 2015-02-10 02:41:30 UTC
Created attachment 989919 [details]
make check_i_goal skip dirs whose goal blocks are not zero

This is an easy fix where fsck.gfs2 doesn't attempt to fix non-zero goal values for directories.

Comment 4 Abhijith Das 2015-02-10 02:51:59 UTC
Created attachment 989920 [details]
another patch that attempts to do more of the right thing

This version deems an existing goal block as valid if it exists in any rgrp in the fs. It does this by checking the inode's goal block against all the rgrps in the fs. While the code tries to avoid checking all the rgrps as much as possible, if it does end up doing this often, then this becomes a very expensive operation.

The patch does the following:
1. If the computed goal_blk for a given inode is equal to the dinode's block, then we haven't really computed much and this is a worst-case correct value for the goal.
2. If we don't have a better computed goal (i.e 1. is true), we check if the existing goal block is valid using check_valid_block()
3. check_valid_block() tries to avoid running through all the rgrps by checking the following things first:
   a) If the block is out of bounds of the filesystem, it's invalid.
   b) If the block belongs to the same rgrp as that of the dinode, it is valid.
   c) Warn the user that further investigation might take time and get her consent before finally resorting to check all the rgrps for this block.
   d) If the block is found, we assume it is valid... invalid otherwise.

Comment 5 Abhijith Das 2015-02-11 15:49:31 UTC
Created attachment 990481 [details]
make check_i_goal skip dirs whose goal blocks are out of fs bounds

This is a slight improvement over the first patch where check_i_goal assumes a block that falls within the fs bounds is valid for a directory's allocation goal block and skips such directories.

Comment 10 Abhijith Das 2015-04-17 15:03:14 UTC
Some issues were discovered during testing of randomly allocated
inodes where the kernel and fsck.gfs2 disagree on what their goal
blocks should be. The conclusion at this point is that fsck.gfs2
is neither able to compute the goal block accurately nor verify if
a given block is definitely the goal block of an inode.

So, we revert the previous patches that attempted to compute the
i_goal and fall back to a simpler logic where we set the i_goal of
an inode to the inode metadata block if we find that the existing
value is definitely wrong (i.e out of bounds of the fs).

https://git.fedorahosted.org/cgit/gfs2-utils.git/commit/ is the
upstream patch and the RHEL7 version has been pushed too.

Comment 13 Nate Straz 2015-08-06 13:49:39 UTC
Verified with gfs2-utils-3.1.8-4.el7.x86_64

After running d_io on a file system, fsck.gfs2 no longer complains about directory i_goal values.

[root@host-025 3.post]# cat 4.fsck/cmd.log
Initializing fsck
Validating Resource Group index.
Level 1 rgrp check: Checking if all rgrp and rindex values are good.
(level 1 passed)
Starting pass1
pass1 completed in 0.168s
Starting pass1b
pass1b completed in 0.000s
Starting pass1c
pass1c completed in 0.001s
Starting pass2
pass2 completed in 0.047s
Starting pass3
pass3 completed in 0.000s
Starting pass4
pass4 completed in 0.000s
Starting pass5
pass5 completed in 0.027s
Starting check_statfs
check_statfs completed in 0.000s
gfs2_fsck complete

Comment 15 errata-xmlrpc 2015-11-19 03:53:31 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, 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-2015-2178.html