From: "Holger Hoffstätte" <holger@applied-asynchrony.com>
To: dsterba@suse.cz, Josef Bacik <josef@toxicpanda.com>,
linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH][RESEND] btrfs: kill update_block_group_flags
Date: Tue, 30 Jun 2020 11:22:08 +0200 [thread overview]
Message-ID: <bbd85d2d-5490-0797-0649-616531c977fe@applied-asynchrony.com> (raw)
In-Reply-To: <20200302201804.GX2902@twin.jikos.cz>
On 2020-03-02 21:18, David Sterba wrote:
> On Sun, Mar 01, 2020 at 06:58:02PM +0100, Holger Hoffstätte wrote:
>> On 1/17/20 3:08 PM, Josef Bacik wrote:
>>> + alloc_flags = btrfs_get_alloc_profile(fs_info, cache->flags);
>>> if (alloc_flags != cache->flags) {
>>> ret = btrfs_chunk_alloc(trans, alloc_flags,
>>> CHUNK_ALLOC_FORCE);
>>> @@ -2252,7 +2204,7 @@ int btrfs_inc_block_group_ro(struct btrfs_block_group *cache,
>>> ret = inc_block_group_ro(cache, 0);
>>> out:
>>> if (cache->flags & BTRFS_BLOCK_GROUP_SYSTEM) {
>>> - alloc_flags = update_block_group_flags(fs_info, cache->flags);
>>> + alloc_flags = btrfs_get_alloc_profile(fs_info, cache->flags);
>>> mutex_lock(&fs_info->chunk_mutex);
>>> check_system_chunk(trans, alloc_flags);
>>> mutex_unlock(&fs_info->chunk_mutex);
>>>
>>
>> It seems that this patch breaks forced metadata rebalance from dup to single;
>> all chunks remain dup (or are rewritten as dup again). I bisected the broken
>> balance behaviour to this commit which for some reason was in my tree ;-) and
>> reverting it immediately fixed things.
>>
>> I don't (yet) see this applied anywhere, but couldn't find any discussion or
>> revocation either. Maybe the logic between update_block_group_flags() and
>> btrfs_get_alloc_profile() is not completely exchangeable?
>
> The patch was not applied because I was not sure about it and had some
> suspicion, https://lore.kernel.org/linux-btrfs/20200108170340.GK3929@twin.jikos.cz/
> I don't want to apply the patch until I try the mentioned test with
> raid1c34 but it's possible that it gets fixed by the updated patch.
I don't see this in misc-next or anywhere else, so a gentle reminder..
Original thread:
https://lore.kernel.org/linux-btrfs/20200117140826.42616-1-josef@toxicpanda.com/
As I wrote in the replies, the update to the patch fixed the balancing for me
(used with various profiles since then, no observed issues).
Josef, what about that xfstest?
David, can you try again with raid1c34?
thanks
Holger
next prev parent reply other threads:[~2020-06-30 9:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-17 14:08 [PATCH][RESEND] btrfs: kill update_block_group_flags Josef Bacik
2020-03-01 17:58 ` Holger Hoffstätte
2020-03-02 14:10 ` Josef Bacik
2020-03-02 15:02 ` Holger Hoffstätte
2020-03-02 20:18 ` David Sterba
2020-06-30 9:22 ` Holger Hoffstätte [this message]
2020-06-30 13:35 ` Josef Bacik
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=bbd85d2d-5490-0797-0649-616531c977fe@applied-asynchrony.com \
--to=holger@applied-asynchrony.com \
--cc=dsterba@suse.cz \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox