Description of problem: While running some tests against a 2.6.18-245 kernel on an ext3 filesystem for BZ 662838 the fs became corrupted. Running e2fsck failed with this error: sh-3.2# e2fsck -yf /dev/hda3 e2fsck 1.39 (29-May-2006) Pass 1: Checking inodes, blocks, and sizes Inode 876220, i_size is 37433344, should be 37429248. Fix? yes Inode 876220, i_blocks is 73240, should be 73232. Fix? yes Pass 2: Checking directory structure Directory inode 876220 has an unallocated block #9138. Allocate? yes XXX should never happen!!! Aborted Running e4fsck fixed the problem and e2fsck no long reports any errors. An e2image of the corrupted filesystem is available from: file.rdu.redhat.com:~lmcilroy/hda3.e2i.bz2 Version-Release number of selected component (if applicable): kernel-2.6.18-245.el5 e2fsprogs-1.39-23.el5 How reproducible: e2fsck fails every time when run on the e2image.
This upstream commit fixes it: commit d45edec0fb2e5d100d122fdda0914560c64def44 Author: Theodore Ts'o <tytso> Date: Wed Mar 12 16:10:48 2008 -0400 e2fsck: Handle a pass 2 "should never happen" error gracefully Turns out a "should never happen" error can indeed happen very easily if a directory with an htree index has an incorrect, and too-large, i_size field. This patch fixes this so that we handle this situation gracefully, allowing filesystems with this error to be fixed. In another patch I will clean up the specific problem which caused the internal "should never happen" error from happening at all, but patch will prevent e2fsck from crashing, and prompt the user to remove the htree index, so it can be rebuilt again after pass 3. Thanks to Bas van Schaik at Tetra for giving me access to his system so this problem could be debugged. Addresses-Launchpad-Bug: #129395 Signed-off-by: "Theodore Ts'o" <tytso> Thanks, -Eric
Built & tagged in e2fsprogs-1.39-32.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-2011-1080.html