Bug 508978 - gfs_fsck -n always returns 0 even if error is found
Summary: gfs_fsck -n always returns 0 even if error is found
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-utils
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: 5.5
Assignee: Robert Peterson
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-30 18:02 UTC by Jaroslav Kortus
Modified: 2010-03-30 08:55 UTC (History)
1 user (show)

Fixed In Version: gfs-utils-0.1.20-7.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 08:55:50 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0290 0 normal SHIPPED_LIVE gfs-utils bug fix update 2010-03-29 14:09:53 UTC

Description Jaroslav Kortus 2009-06-30 18:02:03 UTC
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 18:20:21 UTC
This is basically just back-porting the patch for bug #474705 from
gfs2 to gfs.

Comment 2 Robert Peterson 2009-09-30 16:32:54 UTC
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 16:23:10 UTC
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 20:33:31 UTC
Build successful.  Changing status to Modified.

Comment 6 Nate Straz 2010-01-08 15:11:35 UTC
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 19:28:13 UTC
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 20:17:17 UTC
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 08:55:50 UTC
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.