Bug 508978 - gfs_fsck -n always returns 0 even if error is found
gfs_fsck -n always returns 0 even if error is found
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-utils (Show other bugs)
5.4
All Linux
low Severity medium
: rc
: 5.5
Assigned To: Robert Peterson
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-30 14:02 EDT by Jaroslav Kortus
Modified: 2010-03-30 04:55 EDT (History)
1 user (show)

See Also:
Fixed In Version: gfs-utils-0.1.20-7.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-30 04:55:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to fix the problem (49.76 KB, patch)
2009-09-30 12:32 EDT, Robert Peterson
no flags Details | Diff

  None (edit)
Description Jaroslav Kortus 2009-06-30 14:02:03 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
Comment 1 Robert Peterson 2009-06-30 14:20:21 EDT
This is basically just back-porting the patch for bug #474705 from
gfs2 to gfs.
Comment 2 Robert Peterson 2009-09-30 12:32:54 EDT
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.
Comment 3 Robert Peterson 2009-10-08 12:23:10 EDT
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.
Comment 4 Robert Peterson 2009-10-08 16:33:31 EDT
Build successful.  Changing status to Modified.
Comment 6 Nate Straz 2010-01-08 10:11:35 EST
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.
Comment 7 Robert Peterson 2010-01-08 14:28:13 EST
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.
Comment 8 Robert Peterson 2010-01-08 15:17:17 EST
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.
Comment 13 errata-xmlrpc 2010-03-30 04:55:50 EDT
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

Note You need to log in before you can comment on or make changes to this bug.