Re: Howto switch off ext4's delayed allocation?

From: Theodore Tso
Date: Thu Sep 17 2009 - 09:34:13 EST


On Wed, Sep 16, 2009 at 02:41:09PM -0400, Clemens Eisserer wrote:
>
> > If you can run a strace on eclipse while and then arrange to edit an
> > existing file and save it, it would be interesting to see what the
> > heck it is doing.
> I'll have a look.

Thanks, but no need. I did some investigating, and when I found that
kwrite was doing a truncate-and-rewrite, I did some more digging, and
found that we had a bug in our truncate hueristics. I'll get this
fixed for 2.6.32, and it will be a candidate for the 2.6.31 stable
tree.

(This needs to get backported for ext3 as well.)

- Ted

commit dbc380bc2268bed9faa687b2ec1f98a7706b5909
Author: Theodore Ts'o <tytso@xxxxxxx>
Date: Thu Sep 17 09:33:32 2009 -0400

ext4: Fix the alloc on close after a truncate hueristic

In an attempt to avoid doing an unneeded flush after opening a
(previously non-existent) file with O_CREAT|O_TRUNC, the code only
triggered the hueristic if ei->disksize was non-zero. Turns out that
the VFS doesn't call ->truncate() if the file doesn't exist, and
ei->disksize is always zero even if the file previously existed. So
remove the test, since it isn't necessary and in fact disabled the
hueristic.

Thanks to Clemens Eisserer that he was seeing problems with files
written using kwrite and eclipse after sudden crashes caused by a
buggy Intel video driver.

Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx>

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 9887a0c..4abd683 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3973,8 +3973,7 @@ void ext4_truncate(struct inode *inode)
if (!ext4_can_truncate(inode))
return;

- if (ei->i_disksize && inode->i_size == 0 &&
- !test_opt(inode->i_sb, NO_AUTO_DA_ALLOC))
+ if (inode->i_size == 0 && !test_opt(inode->i_sb, NO_AUTO_DA_ALLOC))
ei->i_state |= EXT4_STATE_DA_ALLOC_CLOSE;

if (EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/