On 2010-02-19, at 12:53, number9652 wrote:
I hope you decide to continue unconditionally zeroing the journal at
mkfs time.
That will continue to be the default for the time being, unless we can
be sure that there is no possibility of error. That would be possible
in conjunction with the journal checksum patch, if the checksum
function is changed slightly to include the journal UUID.
In this case, block_iterate2 was being used to create a file, but
when the file became big enough to have an extent leaf,
ext2fs_get_extent was returning an extent when it shouldn't have
been. That caused ext2fs_block_iterate2 to go wrong, eventually
calling mkjournal_proc millions of times more than it needed to
(during which it would immediately return). A patch which resolves
this is below. It shows normal mkfs times for me with a 512 MB
journal and passes make check.
Signed-off-by Nic Case <number9652@xxxxxxxxx>
I haven't looked at this from a logic POV, but I tested this with a
1GB journal and it ran the same time with/without specifying "-O
extents" (10s vs. 650s without this patch). I also ran our additional
e2fsck extents tests without errors, and on a couple of my extent-
based filesystems.
Tested-by: Andreas Dilger <adilger@xxxxxxx>
--- lib/ext2fs/extent-orig.c 2010-02-05 08:58:41.000000000 -0600
+++ lib/ext2fs/extent.c 2010-02-19 13:37:32.000000000 -0600
@@ -307,16 +307,12 @@
op = EXT2_EXTENT_DOWN;
} else if (path->left > 0)
op = EXT2_EXTENT_NEXT_SIB;
- else if (handle->level > 0)
- op = EXT2_EXTENT_UP;
else
return EXT2_ET_EXTENT_NO_NEXT;
} else {
/* leaf node */
if (path->left > 0)
op = EXT2_EXTENT_NEXT_SIB;
- else if (handle->level > 0)
- op = EXT2_EXTENT_UP;
else
return EXT2_ET_EXTENT_NO_NEXT;
}
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
