From: Yan Zheng <zheng.yan@oracle.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: linux-btrfs@vger.kernel.org, Chris Mason <chris.mason@oracle.com>
Subject: Re: [PATCH] Fix balance Oops
Date: Fri, 07 Aug 2009 17:07:32 +0800 [thread overview]
Message-ID: <4A7BEED4.90405@oracle.com> (raw)
In-Reply-To: <20090807071952.GS12579@kernel.dk>
On 08/07/2009 03:19 PM, Jens Axboe wrote:
> On Fri, Aug 07 2009, Yan Zheng wrote:
>> On 08/07/2009 02:50 PM, Jens Axboe wrote:
>>> On Fri, Aug 07 2009, Yan Zheng wrote:
>>>> invalidate_inode_pages2_range may return -EBUSY occasionally
>>>> which results Oops. This patch fixes the issue by moving
>>>> invalidate_inode_pages2_range into a loop and keeping calling
>>>> it until the return value is not -EBUSY.
>>>>
>>>> Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
>>>>
>>>> ---
>>>> diff -urp 1/fs/btrfs/relocation.c 2/fs/btrfs/relocation.c
>>>> --- 1/fs/btrfs/relocation.c 2009-07-29 10:03:04.367858774 +0800
>>>> +++ 2/fs/btrfs/relocation.c 2009-08-07 13:26:43.882147138 +0800
>>>> @@ -2553,8 +2553,13 @@ int relocate_inode_pages(struct inode *i
>>>> last_index = (start + len - 1) >> PAGE_CACHE_SHIFT;
>>>>
>>>> /* make sure the dirty trick played by the caller work */
>>>> - ret = invalidate_inode_pages2_range(inode->i_mapping,
>>>> - first_index, last_index);
>>>> + while (1) {
>>>> + ret = invalidate_inode_pages2_range(inode->i_mapping,
>>>> + first_index, last_index);
>>>> + if (ret != -EBUSY)
>>>> + break;
>>>> + cond_resched();
>>>> + }
>>> If it returns EBUSY, would it not make more sense to call
>>> filemap_write_and_wait_range() instead of hammering on invalidate?
>>>
>> The pages to invalidate are not dirty, they are from page read-ahead.
>> Actually I have no idea how invalidate_inode_pages2_range can return
>> -EBUSY here. (the only user of the inode is the balancer, and it does
>> not hold references to the pages)
>
> Weird, I looked it up, and it already does a writeback wait. But I guess
> that's not your issue. Patch still looks like a hack though, it would be
> far better to figure out why it returns EBUSY and fix/wait appropriately
> for that to pass.
>
EBUSY is from the EXTENT_LOCK test in try_release_extent_state. The test
can be true is because some codes call lock_extent while corresponding
pages are not all locked. (one example is btrfs_finish_ordered_io)
Yan, Zheng
next prev parent reply other threads:[~2009-08-07 9:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-07 6:14 [PATCH] Fix balance Oops Yan Zheng
2009-08-07 6:50 ` Jens Axboe
2009-08-07 7:16 ` Yan Zheng
2009-08-07 7:19 ` Jens Axboe
2009-08-07 9:07 ` Yan Zheng [this message]
2009-08-07 12:51 ` Chris Mason
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=4A7BEED4.90405@oracle.com \
--to=zheng.yan@oracle.com \
--cc=chris.mason@oracle.com \
--cc=jens.axboe@oracle.com \
--cc=linux-btrfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.