Bug 160835

Summary:	fsck erroneously reporting bitmap corruption when converting bits from free_metadata -> free_data
Product:	[Retired] Red Hat Cluster Suite	Reporter:	AJ Lewis <157070.alewis>
Component:	gfs	Assignee:	AJ Lewis <157070.alewis>
Status:	CLOSED ERRATA	QA Contact:	GFS Bugs <gfs-bugs>
Severity:	high	Docs Contact:
Priority:	medium
Version:	3	CC:	axel.thimm, tao
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	RHBA-2005-723	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-10-10 15:25:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	160409
Bug Blocks:

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.