This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 160835 - fsck erroneously reporting bitmap corruption when converting bits from free_metadata -> free_data
fsck erroneously reporting bitmap corruption when converting bits from free_m...
Status: CLOSED ERRATA
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
3
All Linux
medium Severity high
: ---
: ---
Assigned To: AJ Lewis
GFS Bugs
:
Depends On: 160409
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-17 14:50 EDT by AJ Lewis
Modified: 2010-01-11 22:05 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2005-723
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-10 11:25:45 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)

  None (edit)
Description AJ Lewis 2005-06-17 14:50:13 EDT
+++ This bug was initially created as a clone of Bug #160409 +++

Description of problem:
I get errors if i run bonnie++ on a gfs fs, cleanly unmount it, and then fsck
it.  When I dug a bit deeper, it turns out that all the bitmap changes are just
converting free_metadata bits to free_data bits - this is a side affect of the
way the fsck checks things and gfs handles freeing metadata.  GFS doesn't clear
out metadata right away when it's unused, it just marks it as free metadata. 
When the fsck check the fs, it doesn't find any references to the free
'metadata', so it thinks it's just free data on the disk.  When pass5 checks the
fsck's bitmaps against the on-disk bitmap, it sees a discrepancy and complains.

The fix that I propose is to silently convert bits that the fsck sees as free
data that are free metadata on-disk.  This protects us from the case that the
bits marked as free metadata are not valid metadata, and doesn't hurt any actual
gfs structure.  So basically it will work exactly as it does now, but it won't
report an error and ask for user input in this case, it will just convert that bit.
Comment 1 AJ Lewis 2005-06-21 14:29:04 EDT
This fix has been committed to the RHEL3 (6.0) GFS branch, and the RHEL4 and
STABLE cluster branches.
Comment 2 AJ Lewis 2005-06-22 10:00:28 EDT
Addendum: It's not completely silent about the change - with normal verbosity,
it says "Converting n unused metadata blocks to free data blocks..."
Comment 4 Red Hat Bugzilla 2005-09-30 10:56:04 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 the 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-2005-723.html
Comment 5 Red Hat Bugzilla 2005-10-07 12:53:43 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 the 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-2005-741.html
Comment 6 Red Hat Bugzilla 2005-10-10 11:25:45 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 the 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-2005-723.html
Comment 7 Axel Thimm 2005-10-10 11:35:15 EDT
Could the wrong reporting of bitmap mismatches happen on RHEL4, too? I had a
case of gfs_fsck repotting but not fixing differing ondisk and fsck bitmaps, see
bug #169687

The contents of the filesystem itself were checked against a copy and no
corruption was found.

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