Red Hat Bugzilla – Bug 160835
fsck erroneously reporting bitmap corruption when converting bits from free_metadata -> free_data
Last modified: 2010-01-11 22:05:49 EST
+++ 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.
This fix has been committed to the RHEL3 (6.0) GFS branch, and the RHEL4 and STABLE cluster branches.
Addendum: It's not completely silent about the change - with normal verbosity, it says "Converting n unused metadata blocks to free data blocks..."
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
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
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.