Bug 232010 - GFS2 gives an invalid metadata block assertion when doing rm/du on mutliple nodes
GFS2 gives an invalid metadata block assertion when doing rm/du on mutliple n...
Status: CLOSED DUPLICATE of bug 231910
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ben Marzinski
Dean Jansa
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-13 11:45 EDT by Josef Bacik
Modified: 2009-05-27 23:30 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-08 16:26:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josef Bacik 2007-03-13 11:45:24 EDT
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 16:26:26 EDT
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.