Bug 458303

Summary: GFS2: fsck reports inconsistency after simultaneous rm -rf.
Product: Red Hat Enterprise Linux 5 Reporter: Nate Straz <nstraz>
Component: kernelAssignee: Robert Peterson <rpeterso>
Status: CLOSED DUPLICATE QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: cluster-maint, edamato
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-12 12:10:00 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:
Attachments:
Description Flags
output from gfs2_edit savemeta /dev/brawl/brawl0, bzip2'd
none
Log from gfs2_fsck -y /dev/brawl/brawl0 none

Description Nate Straz 2008-08-07 15:20:36 UTC 
Created attachment 313702 [details]
output from gfs2_edit savemeta /dev/brawl/brawl0, bzip2'd

Description of problem:

After running the test case in bug 458289 I ran gfs2_fsck on the resulting file system and hit some inconsistency problems.  Attached in the savemeta output from before running gfs2_fsck to fix it.

Version-Release number of selected component (if applicable):
kernel-2.6.18-101.el5

How reproducible:
Unknown, a panic and recovery was involved

Steps to Reproduce:
1. Run genesis to populate file system
2. on all nodes rm -rf gendir*
3. umount file system
4. gfs2_fsck -n
  
Actual results (end of the fsck output):

Bitmap at block 133755 (0x20a7b) left inconsistent
Ondisk and fsck bitmaps differ at block 133756 (0x20a7c) 
Ondisk status is 2 (Invalid) but FSCK thinks it should be 0 (Free)
Metadata type is 0 (free)
Bitmap at block 133756 (0x20a7c) left inconsistent
Ondisk and fsck bitmaps differ at block 133758 (0x20a7e) 
Ondisk status is 1 (Data) but FSCK thinks it should be 0 (Free)
Metadata type is 0 (free)
Bitmap at block 133758 (0x20a7e) left inconsistent
Ondisk and fsck bitmaps differ at block 133777 (0x20a91) 
Ondisk status is 1 (Data) but FSCK thinks it should be 0 (Free)
Metadata type is 0 (free)
Bitmap at block 133777 (0x20a91) left inconsistent
Ondisk and fsck bitmaps differ at block 133779 (0x20a93) 
Ondisk status is 1 (Data) but FSCK thinks it should be 0 (Free)
Metadata type is 0 (free)
Bitmap at block 133779 (0x20a93) left inconsistent
Ondisk and fsck bitmaps differ at block 133791 (0x20a9f) 
Ondisk status is 1 (Data) but FSCK thinks it should be 0 (Free)
Metadata type is 0 (free)
Bitmap at block 133791 (0x20a9f) left inconsistent
Ondisk and fsck bitmaps differ at block 133795 (0x20aa3) 
Ondisk status is 1 (Data) but FSCK thinks it should be 0 (Free)
Metadata type is 0 (free)
Bitmap at block 133795 (0x20aa3) left inconsistent
Ondisk and fsck bitmaps differ at block 133901 (0x20b0d) 
Ondisk status is 1 (Data) but FSCK thinks it should be 0 (Free)
Metadata type is 0 (free)
Bitmap at block 133901 (0x20b0d) left inconsistent
RG #131524 (0x201c4) free count inconsistent: is 63777 should be 64558
Inode count inconsistent: is 631 should be 13
Resource group counts left inconsistent
Pass5 complete      
gfs2_fsck complete

Expected results:
gfs2_fsck should have no complaints about the file system.


Additional info:
Comment 1 RHEL Program Management 2008-08-07 15:32:02 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 2 Nate Straz 2008-08-07 15:49:49 UTC 
Created attachment 313713 [details]
Log from gfs2_fsck -y /dev/brawl/brawl0

After running gfs2_fsck -y on the file system, gfs2_fsck -n came up clean.  Attached is the log from gfs2_fsck -y.
Comment 3 Robert Peterson 2008-08-12 03:58:03 UTC 
I believe that gfs2_fsck was correct in reporting the problems with
the bitmaps.  In this case the problem was caused by bug #458289.
I ran a gfs2_fsck a few times on a file system that is properly managed
with the fix for 458289, and no bitmap problems were reported by gfs2_fsck.
So unless Nate objects, I think I should close this as NOTABUG.
Comment 4 Nate Straz 2008-08-12 12:10:00 UTC 
If the cause of this bug was 458289, let's make it a duplicate of that bug so we can easily see what other things were caused by it.

*** This bug has been marked as a duplicate of bug 458289 ***