[PATCH] ext4: move_extent improve bh vanishing success factor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Xiaoguang Wang has reported sporadic EBUSY failures of ext4/302
Unfortunetly there is nothing we can do if some other task holds
BH's refenrence. So we must return EBUSY in this case. From other
point we can decrease false positive report raito. One of such
cases is filesystem under ENOSPC conditions. We should try to kick
the journal regardless to number of free blocks.

Signed-off-by: Dmitry Monakhov <dmonakhov@xxxxxxxxxx>
---
 fs/ext4/move_extent.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c
index 9f2311b..c2b2b02 100644
--- a/fs/ext4/move_extent.c
+++ b/fs/ext4/move_extent.c
@@ -407,8 +407,10 @@ stop_journal:
 	ext4_journal_stop(handle);
 	/* Buffer was busy because probably is pinned to journal transaction,
 	 * force transaction commit may help to free it. */
-	if (*err == -EBUSY && ext4_should_retry_alloc(orig_inode->i_sb,
-						      &retries))
+	if (*err == -EBUSY &&
+	    (retries++ < 4 && EXT4_SB(orig_inode->i_sb)->s_journal &&
+	     jbd2_journal_force_commit_nested(
+		     EXT4_SB(orig_inode->i_sb)->s_journal)))
 		goto again;
 	return replaced_count;
 
-- 
1.7.1

--
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




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux