Bug 232010 - GFS2 gives an invalid metadata block assertion when doing rm/du on mutliple nodes
Summary: GFS2 gives an invalid metadata block assertion when doing rm/du on mutliple n...
Status: CLOSED DUPLICATE of bug 231910
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.1
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Ben Marzinski
QA Contact: Dean Jansa
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-13 15:45 UTC by Josef Bacik
Modified: 2009-05-28 03:30 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2007-05-08 20:26:26 UTC

Attachments (Terms of Use)

Description Josef Bacik 2007-03-13 15:45:24 UTC
I hit this while trying to reproduce bz 231910, I'm not sure if its related or 
not but I'm filing a different bz to be sure.  I got this while doing an 
rm -rf on a directory with a bunch of files (a kernel source tree) and doing a 
du -h on another node on the same directory.  The node doing the du is the one 
who asserted

rh5cluster2.gsslab.rdu.redhat.com login: GFS2: fsid=rhel5cluster:gfs2lv1.0: 
fatal: invalid metadata block
GFS2: fsid=rhel5cluster:gfs2lv1.0:   bh = 1752064 (type: exp=10, found=8)
GFS2: fsid=rhel5cluster:gfs2lv1.0:   function = ea_foreach_i, file = 
fs/gfs2/eattr.c, line = 80
GFS2: fsid=rhel5cluster:gfs2lv1.0: about to withdraw this file system
GFS2: fsid=rhel5cluster:gfs2lv1.0: telling LM to withdraw
GFS2: fsid=rhel5cluster:gfs2lv1.0: withdrawn
 [<d0a9eb4f>] gfs2_lm_withdraw+0x82/0x8d [gfs2]
 [<d0aafe12>] gfs2_metatype_check_ii+0x5e/0x6b [gfs2]
 [<d0a97cfe>] ea_foreach_i+0x86/0x120 [gfs2]
 [<d0a97dfc>] ea_foreach+0x64/0x1ad [gfs2]
 [<d0a9933a>] ea_find_i+0x0/0x53 [gfs2]
 [<d0a97f6f>] gfs2_ea_find+0x2a/0x37 [gfs2]
 [<d0a99af6>] gfs2_ea_get_i+0x22/0x7d [gfs2]
 [<d0a9a226>] gfs2_ea_get+0x77/0x8a [gfs2]
 [<d0a9a200>] gfs2_ea_get+0x51/0x8a [gfs2]
 [<d0aa6b45>] gfs2_getxattr+0x64/0x70 [gfs2]
 [<c04c0c4a>] inode_doinit_with_dentry+0x15d/0x547
 [<d0a9c111>] gfs2_holder_uninit+0xb/0x1b [gfs2]
 [<d0a9d870>] gfs2_lookupi+0x14e/0x166 [gfs2]
 [<c0490fff>] inotify_d_instantiate+0x41/0x67
 [<c047d16a>] d_instantiate+0x5c/0x60
 [<c047e15a>] d_splice_alias+0xd4/0xe3
 [<c04748a4>] do_lookup+0xa3/0x140
 [<c04765c4>] __link_path_walk+0x7d7/0xc2c
 [<c0476a5d>] link_path_walk+0x44/0xb3
 [<c0476d55>] do_path_lookup+0x172/0x1c2
 [<c0475c47>] getname+0x59/0xad
 [<c0477514>] __user_walk_fd+0x2f/0x40
 [<c04713ee>] vfs_lstat_fd+0x16/0x3d
 [<c047145a>] sys_lstat64+0xf/0x23
 [<c044e5cb>] audit_syscall_entry+0x111/0x143
 [<c0407975>] do_syscall_trace+0x124/0x16b
 [<c0404e4c>] syscall_call+0x7/0xb
inode_doinit_with_dentry:  getxattr returned 5 for dev=dm-2 ino=1752063

Comment 1 Ben Marzinski 2007-05-08 20:26:26 UTC
The problem with bz #231910 was that a glock was getting demoted from exclusive
while buffers associated with it were still on the incore log.  It seems like
that could account for any number of ugly things happening. I'm closing this as
a dup of 231910. If you can see this even with the fix from that bugzilla,
please reopen it.

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

Note You need to log in before you can comment on or make changes to this bug.