From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: do not set log for full commit when creating non-data block groups
Date: Fri, 9 Nov 2018 08:27:35 +0800 [thread overview]
Message-ID: <e65de2b0-a331-4965-44f7-d7f2fc4ccc79@gmx.com> (raw)
In-Reply-To: <CAL3q7H7E+vVLimR1GbjveN1G8Gi5G9K6_v1wnMrtMLBWLeUCiw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2095 bytes --]
On 2018/11/8 下午10:48, Filipe Manana wrote:
> On Thu, Nov 8, 2018 at 2:37 PM Filipe Manana <fdmanana@kernel.org> wrote:
>>
>> On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>
>>>
>>>
>>> On 2018/11/8 下午9:17, fdmanana@kernel.org wrote:
>>>> From: Filipe Manana <fdmanana@suse.com>
>>>>
>>>> When creating a block group we don't need to set the log for full commit
>>>> if the new block group is not used for data. Logged items can only point
>>>> to logical addresses of data block groups (through file extent items) so
>>>> there is no need to for the next fsync to fallback to a transaction commit
>>>> if the new block group is for metadata.
>>>
>>> Is it possible for the log tree blocks to be allocated in that new block
>>> group?
>>
>> Yes.
>
> Now I realize what might be your concern, and this would cause trouble.
> Surprised this didn't trigger any problem and I had this (together
> with other changes) running tests for some weeks already.
Maybe it's related metadata chunk pre-allocation so it will be super
hard to hit in normal case, or some extent allocation policy preventing
us from allocating tree block of newly created bg.
Thanks,
Qu
>
>>
>>>
>>> Thanks,
>>> Qu
>>>
>>>>
>>>> Signed-off-by: Filipe Manana <fdmanana@suse.com>
>>>> ---
>>>> fs/btrfs/extent-tree.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
>>>> index 577878324799..588fbd1606fb 100644
>>>> --- a/fs/btrfs/extent-tree.c
>>>> +++ b/fs/btrfs/extent-tree.c
>>>> @@ -10112,7 +10112,8 @@ int btrfs_make_block_group(struct btrfs_trans_handle *trans, u64 bytes_used,
>>>> struct btrfs_block_group_cache *cache;
>>>> int ret;
>>>>
>>>> - btrfs_set_log_full_commit(fs_info, trans);
>>>> + if (type & BTRFS_BLOCK_GROUP_DATA)
>>>> + btrfs_set_log_full_commit(fs_info, trans);
>>>>
>>>> cache = btrfs_create_block_group_cache(fs_info, chunk_offset, size);
>>>> if (!cache)
>>>>
>>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-11-09 0:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-08 13:17 [PATCH] Btrfs: do not set log for full commit when creating non-data block groups fdmanana
2018-11-08 14:33 ` Qu Wenruo
2018-11-08 14:37 ` Filipe Manana
2018-11-08 14:48 ` Filipe Manana
2018-11-09 0:27 ` Qu Wenruo [this message]
2018-11-09 10:21 ` Filipe Manana
2018-11-09 12:02 ` Qu Wenruo
2018-11-13 14:31 ` David Sterba
2018-11-13 14:44 ` Filipe Manana
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=e65de2b0-a331-4965-44f7-d7f2fc4ccc79@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=fdmanana@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox