Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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...
Keywords:
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
medium
medium
Target Milestone: ---
: ---
Assignee: Ben Marzinski
QA Contact: Dean Jansa
URL:
Whiteboard:
Depends On:
Blocks:
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)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
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.