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> ---
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. http://rhn.redhat.com/errata/RHBA-2009-1413.html