diff mbox

(resend) extent header problems following shrink with resize2fs

Message ID 877i5ozprb.fsf@burly.wgtn.ondioline.org
State Rejected, archived
Headers show

Commit Message

Paul Collins Dec. 25, 2008, 7:18 a.m. UTC 
Theodore Tso <tytso@MIT.EDU> writes:
> Yeah, resize2fs needs to be fixed to handle extents correctly.  At the
> moment it can screw them up pretty badly.

In the meantime, perhaps something like the patch below is appropriate?

> I'll log this as a bug to resize2fs; thanks for reporting it, and I
> hope you didn't suffer any permanent data loss.

No worries there, that was replica N+1 of those particular files.

My real concern, which I didn't highlight well and buried way down in my
original report to boot, was e2fsck blowing up like it did.  Hardware
being what it is, I imagine at some point extent headers will get
corrupted, and losing one file is of course preferable to losing the
entire filesystem.

For reference, here's that backtrace again.

        /dev/sdb1 contains a file system with errors, check forced.
        Pass 1: Checking inodes, blocks, and sizes
        Error1: Corrupt extent header on inode 38979
        [New Thread 0x7fe15e066740 (LWP 24166)]

        Program received signal SIGABRT, Aborted.
        [Switching to Thread 0x7fe15e066740 (LWP 24166)]
        0x00007fe15d0fbed5 in raise () from /lib/libc.so.6
        (gdb) bt
        #0  0x00007fe15d0fbed5 in raise () from /lib/libc.so.6
        #1  0x00007fe15d0fd3f3 in abort () from /lib/libc.so.6
        #2  0x000000000040bdae in scan_extent_node (ctx=0x24c6f70, 
            pctx=0x7fff6607c7a0, pb=0x7fff6607c5f0, start_block=0, ehandle=0x2ed94d0)
            at /build/buildd/e2fsprogs-1.41.3/e2fsck/pass1.c:1700
        #3  0x000000000040cc1d in check_blocks (ctx=0x24c6f70, pctx=0x7fff6607c7a0, 
            block_buf=0x2ec11a0 "�002")
            at /build/buildd/e2fsprogs-1.41.3/e2fsck/pass1.c:1773
        #4  0x000000000040e063 in e2fsck_pass1 (ctx=0x24c6f70)
            at /build/buildd/e2fsprogs-1.41.3/e2fsck/pass1.c:1030
        #5  0x00000000004089e8 in e2fsck_run (ctx=0x24c6f70)
            at /build/buildd/e2fsprogs-1.41.3/e2fsck/e2fsck.c:215
        #6  0x00000000004074a3 in main (argc=<value optimized out>, 
            argv=<value optimized out>)
            at /build/buildd/e2fsprogs-1.41.3/e2fsck/unix.c:1278

Comments

Theodore Ts'o Dec. 25, 2008, 1:09 p.m. UTC | #1 
On Thu, Dec 25, 2008 at 08:18:48PM +1300, Paul Collins wrote:
> My real concern, which I didn't highlight well and buried way down in my
> original report to boot, was e2fsck blowing up like it did.  Hardware
> being what it is, I imagine at some point extent headers will get
> corrupted, and losing one file is of course preferable to losing the
> entire filesystem.

Yeah, I know about that problem.  It was highlighted recently but what
with the end of the year coming up I haven't had a chance to fix it
yet.  It's an embarassing oversight on my part; I didn't notice that I
failed to handle this case because it happens relatively rarely that
an extent tree has a depth >= 2 in the first place, since this error
only happens when an non-leaf interior node gets corrupted.  I had
left it as an "we'll handle this later" case, and I never got back to
it.  The short-term workaround is simply to use debugfs and use the
clri function:

debugfs -w /dev/sdb1
debugfs: clri <38979>
debugfs: quit

... and then run e2fsck.  I'll get this fixed in the next maintenance
release of e2fsprogs, though, which will be out soon.  We have a few
ext4 related problems that I really need to get fixed and out the
door.

	   	      	      	    	    	- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/resize/main.c b/resize/main.c
index 3de333e..fb4fa99 100644
--- a/resize/main.c
+++ b/resize/main.c
@@ -426,6 +426,13 @@  int main (int argc, char ** argv)
 			"long.  Nothing to do!\n\n"), new_size);
 		exit(0);
 	}
+	if ((new_size < fs->super->s_blocks_count) &&
+	    (fs->super->s_feature_incompat & EXT3_FEATURE_INCOMPAT_EXTENTS)) {
+		fprintf(stderr, _("Reducing the size of a "
+				  "filesystem with extents enabled\n"
+				  "is currently not supported.\n"));
+		exit(1);
+	}
 	if (mount_flags & EXT2_MF_MOUNTED) {
 		retval = online_resize_fs(fs, mtpt, &new_size, flags);
 	} else {