From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: <bo.li.liu@oracle.com>, Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC] btrfs: make max inline data can be equal to sectorsize
Date: Mon, 14 Nov 2016 09:55:34 +0800 [thread overview]
Message-ID: <1bbc9b5f-9bdb-d8b6-bbd5-7718ea33dcef@cn.fujitsu.com> (raw)
In-Reply-To: <20161111202210.GB30930@dhcp-whq-twvpn-1-vpnpool-10-159-131-21.vpn.oracle.com>
At 11/12/2016 04:22 AM, Liu Bo wrote:
> On Tue, Oct 11, 2016 at 02:47:42PM +0800, Wang Xiaoguang wrote:
>> If we use mount option "-o max_inline=sectorsize", say 4096, indeed
>> even for a fresh fs, say nodesize is 16k, we can not make the first
>> 4k data completely inline, I found this conditon causing this issue:
>> !compressed_size && (actual_end & (root->sectorsize - 1)) == 0
>>
>> If it retuns true, we'll not make data inline. For 4k sectorsize,
>> 0~4094 dara range, we can make it inline, but 0~4095, it can not.
>> I don't think this limition is useful, so here remove it which will
>> make max inline data can be equal to sectorsize.
>
> It's difficult to tell whether we need this, I'm not a big fan of using
> max_inline size more than the default size 2048, given that most reports
> about ENOSPC is due to metadata and inline may make it worse.
IMHO if we can use inline data extents to trigger ENOSPC more easily,
then we should allow it to dig the problem further.
Just ignoring it because it may cause more bug will not solve the real
problem anyway.
Thanks,
Qu
>
> Thanks,
>
> -liubo
>
>>
>> Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
>> ---
>> fs/btrfs/inode.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>> index ea15520..c0db393 100644
>> --- a/fs/btrfs/inode.c
>> +++ b/fs/btrfs/inode.c
>> @@ -267,8 +267,6 @@ static noinline int cow_file_range_inline(struct btrfs_root *root,
>> if (start > 0 ||
>> actual_end > root->sectorsize ||
>> data_len > BTRFS_MAX_INLINE_DATA_SIZE(root) ||
>> - (!compressed_size &&
>> - (actual_end & (root->sectorsize - 1)) == 0) ||
>> end + 1 < isize ||
>> data_len > root->fs_info->max_inline) {
>> return 1;
>> --
>> 2.9.0
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2016-11-14 1:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 6:47 [RFC] btrfs: make max inline data can be equal to sectorsize Wang Xiaoguang
2016-10-11 15:49 ` Chris Murphy
2016-10-12 3:35 ` Wang Xiaoguang
2016-10-15 22:28 ` Zygo Blaxell
2016-10-26 7:32 ` Wang Xiaoguang
2016-11-11 20:22 ` Liu Bo
2016-11-14 1:55 ` Qu Wenruo [this message]
2016-11-16 16:10 ` David Sterba
2016-11-18 20:58 ` Chris Mason
2016-11-19 8:27 ` Zygo Blaxell
2017-01-02 17:21 ` David Sterba
2016-11-22 7:54 ` Wang Xiaoguang
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=1bbc9b5f-9bdb-d8b6-bbd5-7718ea33dcef@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=bo.li.liu@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wangxg.fnst@cn.fujitsu.com \
/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.