Re: [PATCH][RESEND] btrfs: kill update_block_group_flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/30/20 5:22 AM, Holger Hoffstätte wrote:
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@xxxxxxxxxxxxx/
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@xxxxxxxxxxxxxx/

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?


Ha I was just looking at this patch yesterday trying to remember why it wasn't merged. I'm fixing to re-submit my other work, I'll apply these two patches and re-test and send them as well. Sorry about that,

Josef



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux