Red Hat Bugzilla – Bug 503562
e4fsprogs corruption problems
Last modified: 2009-09-03 10:16:22 EDT
RHEL5.4 currently has e4fsprogs from upstream's e2fsprogs-1.41.5 release. This release has 2 known data corruption cases which are now fixed upstream:
1) Attempting to resize below the minimum allowable size may corrupt the filesystem
2) e2fsck replaying the log may corrupt the filesystem
I'd like to at least pull these 2 upstream patches back for e4fsprogs in 5.4... (this is all still tech preview at this point).
e2fsck: Fix journal replay bug which reverts changes to the bg descriptors
Fix a regression in e2fsprogs 1.41.5 which would undo updates to the
block group descriptors after a journal replay, caused by commit
b7c5b403. We now use ext2fs_free() instead of ext2fs_close() to make
sure we the library will never try to write out superblock or block
Signed-off-by: "Theodore Ts'o" <firstname.lastname@example.org>
From: Eric Sandeen <email@example.com>
Date: Wed, 20 May 2009 21:36:26 +0000 (-0500)
Subject: resize2fs: fix ENOSPC corruption case
resize2fs: fix ENOSPC corruption case
contains an image (for now) which, when resized to 578639, corrupts
This is a bit crazy, I guess, because the fs currently has only
1 free block, but still, we should be graceful about the failure.
Perhaps it would make sense to check the requested valuea against
the minimum value resize2fs would compute for "-P" and fail (at
least without a force).
But in any case, this exposed 2 bugs when moving that one block
required an extent split, which is what hit the ENOSPC.
For starters, ext2fs_extent_set_bmap() in the "(re/un)mapping last
block in extent" case was replacing the old extent before the
new one was created; when the new extent creation failed, it
left us in an inconsistent state. Simply changing the order of
the two should fix this problem.
Next, ext2fs_extent_insert was calling ext2fs_extent_delete()
on *any* error, including one caused by failure to allocate a new
block to split the node to hold that extent ... the handle was left
unchanged, and we deleted the -original- extent.
As a quick fix for this, just don't do the delete if we fail the split,
though this may need to be smarter. I don't think we have terribly
consistent behavior about where a handle is left on various errors.
Signed-off-by: Eric Sandeen <firstname.lastname@example.org>
Signed-off-by: Theodore Ts'o <email@example.com>
Built in e4fsprogs-1.41.5-2.el5
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.