Message ID | 1363106209-1883-1-git-send-email-lczerner@redhat.com |
---|---|
State | Accepted, archived |
Headers | show |
Thanks, applied. I'm on the fence about whether to submit this after -rc2 or not. This appears to make potential bug much rarer, and it's a trivial patch to backport, but it does make rather large changes in how we handle fragmented filesystem. (For the better, but it's a large change, and it is getting rather late in the season.) I'm going to include in the dev branch for now, and give it all a good instensive testing, but there may be some patches in dev that may get deferred to the next merge window before I send a pull request to Linus (probably during the coming weekend). Folks should feel free to propose patches they think should wait for the next merge window. - 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
On Tue, 12 Mar 2013, Theodore Ts'o wrote: > Date: Tue, 12 Mar 2013 12:45:11 -0400 > From: Theodore Ts'o <tytso@mit.edu> > To: Lukas Czerner <lczerner@redhat.com> > Cc: linux-ext4@vger.kernel.org, wenqing.lz@taobao.com > Subject: Re: [PATCH] ext4: use s_extent_max_zeroout_kb value as number of kb > > Thanks, applied. > > I'm on the fence about whether to submit this after -rc2 or not. > This appears to make potential bug much rarer, and it's a trivial > patch to backport, but it does make rather large changes in how we > handle fragmented filesystem. (For the better, but it's a large > change, and it is getting rather late in the season.) > > I'm going to include in the dev branch for now, and give it all a good > instensive testing, but there may be some patches in dev that may get > deferred to the next merge window before I send a pull request to > Linus (probably during the coming weekend). > > Folks should feel free to propose patches they think should wait for > the next merge window. > > - Ted Hi Ted, in my opinion this should go in sooner rather than later, because even though it changes the behaviour quite significantly, it also brings back the old (expected) behaviour which has been changed by accident with that bug. Anyway, I am going to run couple of more tests with that patch as well. Thanks! -Lukas -- 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 --git a/fs/ext4/extents.c b/fs/ext4/extents.c index cac80120..aeb80bc 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3227,7 +3227,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, if (EXT4_EXT_MAY_ZEROOUT & split_flag) max_zeroout = sbi->s_extent_max_zeroout_kb >> - inode->i_sb->s_blocksize_bits; + (inode->i_sb->s_blocksize_bits - 10); /* If extent is less than s_max_zeroout_kb, zeroout directly */ if (max_zeroout && (ee_len <= max_zeroout)) {
Currently when converting extent to initialized, we have to decide whether to zeroout part/all of the uninitialized extent in order to avoid extent tree growing rapidly. The decision is made by comparing the size of the extent with the configurable value s_extent_max_zeroout_kb which is in kibibytes units. However when converting it to number of blocks we currently use it as it was in bytes. This is obviously bug and it will result in ext4 _never_ zeroout extents, but rather always split and convert parts to initialized while leaving the rest uninitialized in default setting. Fix this by using s_extent_max_zeroout_kb as kibibytes. Signed-off-by: Lukas Czerner <lczerner@redhat.com> --- fs/ext4/extents.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)