Bug 503562 - e4fsprogs corruption problems
e4fsprogs corruption problems
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: e4fsprogs (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Eric Sandeen
Depends On:
  Show dependency treegraph
Reported: 2009-06-01 13:59 EDT by Eric Sandeen
Modified: 2009-09-03 10:16 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 06:03:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eric Sandeen 2009-06-01 13:59:49 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).

X-Git-Url: http://git.kernel.org/?p=fs%2Fext2%2Fe2fsprogs.git;a=commitdiff_plain;h=27a407df546eafa54f3f50c470e3a0a4c788fae5

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
group descriptors.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

From: Eric Sandeen <sandeen@redhat.com>
Date: Wed, 20 May 2009 21:36:26 +0000 (-0500)
Subject: resize2fs: fix ENOSPC corruption case
X-Git-Tag: v1.41.6~25
X-Git-Url: http://git.kernel.org/?p=fs%2Fext2%2Fe2fsprogs.git;a=commitdiff_plain;h=53422e8a5644e22ea3f6e0efba82a765b72e4308

resize2fs: fix ENOSPC corruption case

contains an image (for now) which, when resized to 578639, corrupts
the filesystem.

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 <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Comment 2 Eric Sandeen 2009-06-02 11:53:30 EDT
Built in e4fsprogs-1.41.5-2.el5
Comment 7 errata-xmlrpc 2009-09-02 06:03:56 EDT
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.


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