Red Hat Bugzilla – Bug 508978
gfs_fsck -n always returns 0 even if error is found
Last modified: 2010-03-30 04:55:50 EDT
Description of problem:
gfs_fsck -n always exits with 0. It should exit with non-zero if any inconsistency is found (as gfs2_fsck does).
Version-Release number of selected component (if applicable):
GFS fsck 0.1.19 (built May 4 2009 19:34:42)
Steps to Reproduce:
1. create inconsistent filesystem
2. run gfs_fsck -n
3. echo $?
last command is always 0
non-zero exit value should be returned
This is basically just back-porting the patch for bug #474705 from
gfs2 to gfs.
Created attachment 363203 [details]
Patch to fix the problem
This patch was tested with a variety of damaged GFS metadata on
system roth-01 and I verified the proper return codes were given,
at least for $? == 0, 1, 4 and 8. However, my metadata collection
obviously doesn't test all possible scenarios.
The patch was pushed to the master branch of the gfs1-utils git
tree, and the RHEL55 and STABLE3 branches of the cluster git tree
for inclusion into 5.5. It was tested on system roth-01.
Changing status to POST.
Build successful. Changing status to Modified.
During gfs2_convert testing we run gfs_fsck -n on a populated file system to make sure it is clean. gfs_fsck attempts convert unused metadata blocks to free data blocks but can't because of the -n option. This causes gfs_fsck to return 4 indicating errors were not fixed.
gfs_fsck either shouldn't try to convert unused metadata blocks to free data blocks when -n is specified or it should indicate that it was not able to convert the blocks or not could this as an uncorrected error.
The gfs_fsck program should not try to reclaim free metadata blocks
when -n is specified on the command line (although it may still
report that it's an issue).
The problem was found and fixed. There were two upstream commits
to gfs1-utils master: 60c67a9 and 8345fb9. There were two upstream
commits to cluster STABLE3: cf9c5e1 and 75d28b6. These were
combined into a single commit for the RHEL55: dd3b502.
The upstream patches were tested on system kool. The RHEL55 patches
were tested on system roth-01. They were pushed to their respective
Changing status to POST until I can get this into a build.
Build 2182072 is finished and successful. This regression is fixed
in gfs-utils-0.1.20-7.el5.src.rpm. Changing status back to
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.