Bug 503562

Summary: e4fsprogs corruption problems
Product: Red Hat Enterprise Linux 5 Reporter: Eric Sandeen <esandeen>
Component: e4fsprogsAssignee: Eric Sandeen <esandeen>
Status: CLOSED ERRATA QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: low    
Version: 5.4   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 10:03:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Eric Sandeen 2009-06-01 17:59:49 UTC
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>
---

From: Eric Sandeen <sandeen>
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

http://people.redhat.com/esandeen/livecd-creator-imagefile.bz2
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>
Signed-off-by: Theodore Ts'o <tytso>
---

Comment 2 Eric Sandeen 2009-06-02 15:53:30 UTC
Built in e4fsprogs-1.41.5-2.el5

Comment 7 errata-xmlrpc 2009-09-02 10:03:56 UTC
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.

http://rhn.redhat.com/errata/RHBA-2009-1413.html