Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Wang Yugui <wangyugui@e16-tech.com>, Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: fix the max chunk size and stripe length calculation
Date: Thu, 18 Aug 2022 16:13:16 +0800	[thread overview]
Message-ID: <69f30de8-0d1d-4ada-c563-6f88bc4a4f40@gmx.com> (raw)
In-Reply-To: <20220818160425.511E.409509F4@e16-tech.com>



On 2022/8/18 16:04, Wang Yugui wrote:
> Hi,
>
>> [BEHAVIOR CHANGE]
>> Since commit f6fca3917b4d ("btrfs: store chunk size in space-info
>> struct"), btrfs no longer can create larger data chunks than 1G:
>>
>>    mkfs.btrfs -f -m raid1 -d raid0 $dev1 $dev2 $dev3 $dev4
>>    mount $dev1 $mnt
>>
>>    btrfs balance start --full $mnt
>>    btrfs balance start --full $mnt
>>    umount $mnt
>>
>>    btrfs ins dump-tree -t chunk $dev1 | grep "DATA|RAID0" -C 2
>>
>> Before that offending commit, what we got is a 4G data chunk:
>>
>> 	item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 9492758528) itemoff 15491 itemsize 176
>> 		length 4294967296 owner 2 stripe_len 65536 type DATA|RAID0
>> 		io_align 65536 io_width 65536 sector_size 4096
>> 		num_stripes 4 sub_stripes 1
>>
>> Now what we got is only 1G data chunk:
>>
>> 	item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 6271533056) itemoff 15491 itemsize 176
>> 		length 1073741824 owner 2 stripe_len 65536 type DATA|RAID0
>> 		io_align 65536 io_width 65536 sector_size 4096
>> 		num_stripes 4 sub_stripes 1
>>
>> This will increase the number of data chunks by the number of devices,
>> not only increase system chunk usage, but also greatly increase mount
>> time.
>>
>> Without a properly reason, we should not change the max chunk size.
>>
>> [CAUSE]
>> Previously, we set max data chunk size to 10G, while max data stripe
>> length to 1G.
>>
>> Commit f6fca3917b4d ("btrfs: store chunk size in space-info struct")
>> completely ignored the 10G limit, but use 1G max stripe limit instead,
>> causing above shrink in max data chunk size.
>>
>> [FIX]
>> Fix the max data chunk size to 10G, and in decide_stripe_size_regular()
>> we limit stripe_size to 1G manually.
>>
>> This should only affect data chunks, as for metadata chunks we always
>> set the max stripe size the same as max chunk size (256M or 1G
>> depending on fs size).
>>
>> Now the same script result the same old result:
>>
>> 	item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 9492758528) itemoff 15491 itemsize 176
>> 		length 4294967296 owner 2 stripe_len 65536 type DATA|RAID0
>> 		io_align 65536 io_width 65536 sector_size 4096
>> 		num_stripes 4 sub_stripes 1
>>
>> Reported-by: Wang Yugui <wangyugui@e16-tech.com>
>> Fixes: f6fca3917b4d ("btrfs: store chunk size in space-info struct")
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>   fs/btrfs/space-info.c | 2 +-
>>   fs/btrfs/volumes.c    | 3 +++
>>   2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
>> index 477e57ace48d..b74bc31e9a8e 100644
>> --- a/fs/btrfs/space-info.c
>> +++ b/fs/btrfs/space-info.c
>> @@ -199,7 +199,7 @@ static u64 calc_chunk_size(const struct btrfs_fs_info *fs_info, u64 flags)
>>   	ASSERT(flags & BTRFS_BLOCK_GROUP_TYPE_MASK);
>>
>>   	if (flags & BTRFS_BLOCK_GROUP_DATA)
>> -		return SZ_1G;
>> +		return BTRFS_MAX_DATA_CHUNK_SIZE;
>>   	else if (flags & BTRFS_BLOCK_GROUP_SYSTEM)
>>   		return SZ_32M;
>>
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index 8c64dda69404..e0fd1aecf447 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -5264,6 +5264,9 @@ static int decide_stripe_size_regular(struct alloc_chunk_ctl *ctl,
>>   				       ctl->stripe_size);
>>   	}
>>
>> +	/* Stripe size should never go beyond 1G. */
>
> Currently we  limit  the stripe size to SIZE_1G.
>
> Is there some technical limit such as 'used as signed 32bit, so max
> SIZE_1G or SIZE_2G?' or 'used as unsigned 32bit, so max SIZE_2G or
> SIZE_4G?'

AFAIK the only problem with larger stripe size is for unbalanced
data/metadata case it will be harder to reclaim block groups.

Other than that I'm not aware of certain problems related the stripe size.

Thanks,
Qu
>
> Best Regards
> Wang Yugui (wangyugui@e16-tech.com)
> 2022/08/18
>
>
>> +	ctl->stripe_size = min_t(u64, ctl->stripe_size, SZ_1G);
>> +
>>   	/* Align to BTRFS_STRIPE_LEN */
>>   	ctl->stripe_size = round_down(ctl->stripe_size, BTRFS_STRIPE_LEN);
>>   	ctl->chunk_size = ctl->stripe_size * data_stripes;
>> --
>> 2.37.1
>
>

  reply	other threads:[~2022-08-18  8:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-18  7:06 [PATCH] btrfs: fix the max chunk size and stripe length calculation Qu Wenruo
2022-08-18  8:04 ` Wang Yugui
2022-08-18  8:13   ` Qu Wenruo [this message]
2022-09-06 16:01 ` David Sterba
2022-09-07 10:37 ` Wang Yugui
2022-09-07 10:44   ` Qu Wenruo
2022-09-14 21:54 ` 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=69f30de8-0d1d-4ada-c563-6f88bc4a4f40@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wangyugui@e16-tech.com \
    --cc=wqu@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox