This is more or less a clone of bug #623666 fs corruption with xfstests for ext4 The same problem exists on the rhel5 backport, but it wasn't caught because the xfstests test (241) wasn't running dbench long enough to hit it reliably. The fix is the same: diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c index 22b59c8..b71c331 100644 --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -242,8 +242,9 @@ void ext4_free_inode(handle_t *handle, struct inode *inode) goto error_return; /* Ok, now we can actually update the inode bitmaps.. */ - cleared = ext4_clear_bit_atomic(ext4_group_lock_ptr(sb, block_group), - bit, bitmap_bh->b_data); + ext4_lock_group(sb, block_group); + cleared = ext4_clear_bit(bit, bitmap_bh->b_data); + ext4_unlock_group(sb, block_group); if (!cleared) ext4_error(sb, "bit already cleared for inode %lu", ino); else {
The end result of the big is inode bitmap corruption/mismatches: e4fsck 1.41.12 (17-May-2010) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information !./Inode bitmap differences: -1700621 -1700633 -1700743 -1700880 -1700886 -1700895 -1700914 -1700917 -1700922 -1700934 -1700940 -1700944 -1700948 -1700954 -1700956 -1700958 -1700971 -1700980 -1700986 -1700998 -1701005 Fix? yes
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.
Setting for 5.7 since we want to propose this for zstream. This is filesystem corruption.
*** This bug has been marked as a duplicate of bug 663563 ***