Bug 740567

Summary:	GFS2: withdraw in gfs2_setbit during rm/unlink/delete
Product:	Red Hat Enterprise Linux 6	Reporter:	Robert Peterson <rpeterso>
Component:	kernel	Assignee:	Robert Peterson <rpeterso>
Status:	CLOSED NOTABUG	QA Contact:	Cluster QE <mspqa-list>
Severity:	urgent	Docs Contact:
Priority:	high
Version:	6.2	CC:	swhiteho
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:	2011-09-28 04:31:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Robert Peterson 2011-09-22 13:45:18 UTC

Description of problem:
I was trying to test the performance of file deletes in RHEL6.2
using the 2.6.32-201.el6.x86_64 kernel and it gave an error and
withdrew.  This was done after a successful fsck.gfs2, so the
file system was clean.

Version-Release number of selected component (if applicable):
RHEL6.2

How reproducible:
Twice in a row, so it seems pretty reproducible

Steps to Reproduce:
1.time gfs2_edit restoremeta /home/bob/metadata/gfs2/1000dirs.1000files.of.24k.meta /dev/intec/intec1
2.mount -tgfs2 /dev/intec/intec1 /mnt/gfs2
3.time rm -fR /mnt/gfs2/*
  
Actual results:
GFS2: fsid=intec_cluster:gfs2.1: fatal: filesystem consistency error
GFS2: fsid=intec_cluster:gfs2.1:   RG = 198193
GFS2: fsid=intec_cluster:gfs2.1:   function = gfs2_setbit, file = fs/gfs2/rgrp.c, line = 95
GFS2: fsid=intec_cluster:gfs2.1: about to withdraw this file system
GFS2: fsid=intec_cluster:gfs2.1: telling LM to unmount
GFS2: fsid=intec_cluster:gfs2.1: withdrawn
Pid: 7421, comm: rm Not tainted 2.6.32-201.el6.x86_64 #1
Call Trace:
 [<ffffffffa038fa82>] ? gfs2_lm_withdraw+0x102/0x130 [gfs2]
 [<ffffffff81090b3f>] ? wake_up_bit+0x2f/0x40
 [<ffffffffa038fc2a>] ? gfs2_consist_rgrpd_i+0x4a/0x50 [gfs2]
 [<ffffffffa038a780>] ? rgblk_free+0x1f0/0x200 [gfs2]
 [<ffffffffa038a95a>] ? gfs2_unlink_di+0x4a/0xe0 [gfs2]
 [<ffffffffa0374cda>] ? gfs2_change_nlink+0xba/0x140 [gfs2]
 [<ffffffffa03831be>] ? gfs2_rmdiri+0xce/0x110 [gfs2]
 [<ffffffffa03833f3>] ? gfs2_rmdir+0x1f3/0x250 [gfs2]
 [<ffffffff8118d029>] ? d_kill+0x49/0x60
 [<ffffffffa0383285>] ? gfs2_rmdir+0x85/0x250 [gfs2]
 [<ffffffffa03832a7>] ? gfs2_rmdir+0xa7/0x250 [gfs2]
 [<ffffffffa03832d8>] ? gfs2_rmdir+0xd8/0x250 [gfs2]
 [<ffffffffa038ac70>] ? gfs2_rindex_hold+0x40/0xe0 [gfs2]
 [<ffffffff811839dd>] ? vfs_rmdir+0xbd/0xf0
 [<ffffffff8118464a>] ? lookup_hash+0x3a/0x50
 [<ffffffff81186463>] ? do_rmdir+0x103/0x120
 [<ffffffff810d4602>] ? audit_syscall_entry+0x272/0x2a0
 [<ffffffff811864ad>] ? sys_unlinkat+0x2d/0x40
 [<ffffffff8100b0b2>] ? system_call_fastpath+0x16/0x1b

Expected results:
No errors, all files/directories deleted.

Additional info:
Metadata is on gfs-a16c-01.mpc.lab.eng.bos.redhat.com
in /home/bob/metadata/gfs2/

Comment 1 Robert Peterson 2011-09-28 04:31:46 UTC

This problem was user error. It was apparently caused because
I did gfs2_edit restoremeta and friends while the file system
was mounted on other nodes.  If I'm careful not to do stupid
things like that, I don't get these errors.  Closing as NOTABUG.