From: Theodore Ts'o <tytso@mit.edu>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: move_extent improve bh vanishing success factor
Date: Wed, 5 Nov 2014 11:53:49 -0500 [thread overview]
Message-ID: <20141105165349.GE27083@thunk.org> (raw)
In-Reply-To: <1413620984-7736-1-git-send-email-dmonakhov@openvz.org>
On Sat, Oct 18, 2014 at 12:29:44PM +0400, Dmitry Monakhov wrote:
> 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@openvz.org>
Thanks, applied but I did modify the patch slightly because we weren't
actually properly handling the ENOSPC case (we were checking for the
wrong error code).
- Ted
commit 88c6b61ff1cfb4013a3523227d91ad11b2892388
Author: Dmitry Monakhov <dmonakhov@openvz.org>
Date: Wed Nov 5 11:52:38 2014 -0500
ext4: move_extent improve bh vanishing success factor
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. But we can try
kicking the journal to see if the other task releases the bh reference
after the commit is complete. Also decrease false positives by
properly checking for ENOSPC and retrying the allocation after kicking
the journal --- which is done by ext4_should_retry_alloc().
[ Modified by tytso to properly check for ENOSPC. ]
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c
index 9f2311b..503ea15 100644
--- a/fs/ext4/move_extent.c
+++ b/fs/ext4/move_extent.c
@@ -273,6 +273,7 @@ move_extent_per_page(struct file *o_filp, struct inode *donor_inode,
int replaced_count = 0;
int from = data_offset_in_page << orig_inode->i_blkbits;
int blocks_per_page = PAGE_CACHE_SIZE >> orig_inode->i_blkbits;
+ struct super_block *sb = orig_inode->i_sb;
/*
* It needs twice the amount of ordinary journal buffers because
@@ -405,10 +406,13 @@ unlock_pages:
page_cache_release(pagep[1]);
stop_journal:
ext4_journal_stop(handle);
+ if (*err == -ENOSPC &&
+ ext4_should_retry_alloc(sb, &retries))
+ goto again;
/* 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(sb)->s_journal &&
+ jbd2_journal_force_commit_nested(EXT4_SB(sb)->s_journal))
goto again;
return replaced_count;
prev parent reply other threads:[~2014-11-05 16:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-18 8:29 [PATCH] ext4: move_extent improve bh vanishing success factor Dmitry Monakhov
2014-11-05 16:53 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141105165349.GE27083@thunk.org \
--to=tytso@mit.edu \
--cc=dmonakhov@openvz.org \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).