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-utils-0.1.19-3.el5 GFS fsck 0.1.19 (built May 4 2009 19:34:42) How reproducible: always Steps to Reproduce: 1. create inconsistent filesystem 2. run gfs_fsck -n 3. echo $? Actual results: last command is always 0 Expected results: non-zero exit value should be returned Additional info: n/a
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 git repositories. 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 Modified.
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-2010-0290.html