include ext4

[Theodore Tso]

On Tue, Sep 30, 2008 at 02:06:47PM +0100, Scott James Remnant wrote:
> When do you expect ext4 to be stable enough to be a default?  I
> understood F10 to be shipping alongside 8.10, which implies 2.6.27 and
> it's still "in development" there?

Well, it helps that Eric Sandeen from Red Hat is fairly actively
working on ext4.  As far as I know, Fedora 10 isn't going to ship at
as the default, but they will be supporting it in their installer, and
I believe without needing some kind of magic boot option to the
installer. 

> Intrepid has 2.6.27 (rc6? but aiming for release), but only e2fsprogs
> 1.41.0.
> 
> How much would you recommend a version update of e2fsprogs, even if we
> don't do anything with ext4 -- I suspect the latter is unlikely, but
> something we could look into for 9.04

I just released e2fsprogs 1.41.2 this morning.  Most of the bug fixes
between v1.41.0 and v1.41.2 are ext4 specific, although there are a
lot of man page clarifications, updated translations that aren't in
1.41.0, etc.  There is also fixes to Launchpad bugs 246892, and
275272, as well as a host of minor bugs via Debian and Red Hat.

The really big bug fix which is in e2fsprogs 1.41.2 which I think
makes 1.41.2 worth fixes a regression since 1.40.7 which causes
"e2fsck -b 32768 /dev/XXX" to fail, which affects ext2, ext3, and ext4
filesystems that are corrupted badly enough that e2fsck may suggest to
the user to use the backup superblock via "e2fsck -b 32768" or "e2fsck
-b 8193".  In many cases e2fsck will just automatically fall back do
this automatically, but there are a few cases were it will tell the
user to do that --- and then it won't work, unless the user explicitly
specifies the filesystem blocksize via the -B option.

If you don't want to go to e2fsprogs 1.41.2, I'd strongly urge
cherry-picking git commit 52771ab5 in the e2fsprogs repository.  It's
a one-line patch, which I've attached below.  (I really wish the
Ubuntu users could be trained to report serious bugs in Launchpad, and
and yet not report bugs obviously caused by hardware or operator
error, but oh, well....)

							- Ted

commit 52771ab59145d66b50399a8b953b8181cb2d5b04
Author: Theodore Ts'o <tytso at mit.edu>
Date:   Tue Sep 9 15:02:24 2008 -0400

    e2fsck: Fix e2fsck automatic blocksize detetion
    
    This fixes a regression that was introduced in commit dcc91e10 (it
    showed up first in e2fsprogs 1.40.7).  Since we weren't freeing the
    filesystem handle, ext2fs_open2() was returning EBUSY, and so this
    caused a failure in the code that would automatically determine the
    filesystem block size when only the superblock number was specified by
    the user.
    
    This was discussed in http://ubuntuforums.org/showthread.php?t=789323,
    and Matthias Bannach pointed this out to me, for which I am very
    grateful.
    
    Signed-off-by: "Theodore Ts'o" <tytso at mit.edu>

diff --git a/e2fsck/unix.c b/e2fsck/unix.c
index 94938a4..64faebe 100644
--- a/e2fsck/unix.c
+++ b/e2fsck/unix.c
@@ -971,6 +971,8 @@ restart:
 		int blocksize;
 		for (blocksize = EXT2_MIN_BLOCK_SIZE;
 		     blocksize <= EXT2_MAX_BLOCK_SIZE; blocksize *= 2) {
+			if (fs)
+				ext2fs_free(fs);
 			retval = ext2fs_open2(ctx->filesystem_name,
 					      ctx->io_options, flags,
 					      ctx->superblock, blocksize,