Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160835 - fsck erroneously reporting bitmap corruption when converting bits from free_metadata -> free_data
Summary: fsck erroneously reporting bitmap corruption when converting bits from free_m...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: gfs
Version: 3
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: AJ Lewis
QA Contact: GFS Bugs
URL:
Whiteboard:
Depends On: 160409
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-17 18:50 UTC by AJ Lewis
Modified: 2010-01-12 03:05 UTC (History)
2 users (show)

Fixed In Version: RHBA-2005-723
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-10 15:25:45 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:723 normal SHIPPED_LIVE GFS bug fix update 2005-09-30 04:00:00 UTC
Red Hat Product Errata RHBA-2005:741 normal SHIPPED_LIVE GFS bug fix update 2005-10-07 04:00:00 UTC

Description AJ Lewis 2005-06-17 18:50:13 UTC
+++ 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 18:29:04 UTC
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 14:00:28 UTC
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 14:56:04 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 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 16:53:43 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 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 15:25:45 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 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 15:35:15 UTC
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.