Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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 --]

  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