Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Stefan Roesch <shr@fb.com>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	"kernel-team@fb.com" <kernel-team@fb.com>
Cc: Naohiro Aota <Naohiro.Aota@wdc.com>
Subject: Re: [PATCH] btrfs: sysfs: set / query btrfs stripe size
Date: Tue, 26 Oct 2021 23:58:51 -0700	[thread overview]
Message-ID: <285f0f7f-a2df-7f23-2ba3-8ad3c12293ad@fb.com> (raw)
In-Reply-To: <9a0a442c-8409-3401-da85-9032259a7bc5@opensource.wdc.com>



On 10/26/21 11:51 PM, Damien Le Moal wrote:
> On 2021/10/27 15:28, Johannes Thumshirn wrote:
>> On 26/10/2021 18:59, Stefan Roesch wrote:
>>
>> [...]
>>
>>> +/*
>>> + * Compute stripe size depending on block type.
>>> + */
>>> +static u64 compute_stripe_size(struct btrfs_fs_info *info, u64 flags)
>>> +{
>>> +	if (flags & BTRFS_BLOCK_GROUP_DATA) {
>>> +		return SZ_1G;
>>> +	} else if (flags & BTRFS_BLOCK_GROUP_METADATA) {
>>> +		/* For larger filesystems, use larger metadata chunks */
>>> +		return info->fs_devices->total_rw_bytes > 50ULL * SZ_1G
>>> +			? 5ULL * SZ_1G
>>> +			: SZ_256M;
>>> +	} else if (flags & BTRFS_BLOCK_GROUP_SYSTEM) {
>>> +		return SZ_32M;
>>> +	}
>>> +
>>> +	BUG();
>>> +}
>>> +
>>> +/*
>>> + * Compute chunk size depending on block type and stripe size.
>>> + */
>>> +static u64 compute_chunk_size(u64 flags, u64 max_stripe_size)
>>> +{
>>> +	if (flags & BTRFS_BLOCK_GROUP_DATA)
>>> +		return BTRFS_MAX_DATA_CHUNK_SIZE;
>>> +	else if (flags & BTRFS_BLOCK_GROUP_METADATA)
>>> +		return max_stripe_size;
>>> +	else if (flags & BTRFS_BLOCK_GROUP_SYSTEM)
>>> +		return 2 * max_stripe_size;
>>> +
>>> +	BUG();
>>> +}
>>> +
>>> +/*
>>> + * Update maximum stripe size and chunk size.
>>> + *
>>> + */
>>> +void btrfs_update_space_info_max_alloc_sizes(struct btrfs_space_info *space_info,
>>> +					     u64 flags, u64 max_stripe_size)
>>> +{
>>> +	spin_lock(&space_info->lock);
>>> +	space_info->max_stripe_size = max_stripe_size;
>>> +	space_info->max_chunk_size = compute_chunk_size(flags,
>>> +						space_info->max_stripe_size);
>>> +	spin_unlock(&space_info->lock);
>>> +}
>>> +
>>>  static int create_space_info(struct btrfs_fs_info *info, u64 flags)
>>>  {
>>>  
>>> @@ -203,6 +251,10 @@ static int create_space_info(struct btrfs_fs_info *info, u64 flags)
>>>  	INIT_LIST_HEAD(&space_info->priority_tickets);
>>>  	space_info->clamp = 1;
>>>  
>>> +	space_info->max_stripe_size = compute_stripe_size(info, flags);
>>> +	space_info->max_chunk_size = compute_chunk_size(flags,
>>> +						space_info->max_stripe_size);
>>> +
>>>  	ret = btrfs_sysfs_add_space_info_type(info, space_info);
>>>  	if (ret)
>>>  		return ret;
>>
>> [...]
>>
>>   
>>> +/*
>>> + * Return space info stripe size.
>>> + */
>>> +static ssize_t btrfs_stripe_size_show(struct kobject *kobj,
>>> +				      struct kobj_attribute *a, char *buf)
>>> +{
>>> +	struct btrfs_space_info *sinfo = to_space_info(kobj);
>>> +
>>> +	return btrfs_show_u64(&sinfo->max_stripe_size, &sinfo->lock, buf);
>>> +}
>>
>>
>> This will return the wrong values for a fs on a zoned device.
>> What you could do is:
>>
>> static ssize_t btrfs_stripe_size_show(struct kobject *kobj,
>> 				struct kobj_attribute *a, char *buf)
>>
>> {
>> 	struct btrfs_space_info *sinfo = to_space_info(kobj);
>> 	struct btrfs_fs_info *fs_info = to_fs_info(get_btrfs_kobj(kobj));
>> 	u64 max_stripe_size;
>>
>> 	spin_lock(&sinfo->lock);
>> 	if (btrfs_is_zoned(fs_info))
>> 		max_stripe_size = fs_info->zone_size;
>> 	else
>> 		max_stripe_size = sinfo->max_stripe_size;
>> 	spin_unlock(&sinfo->lock);
> 
> This will not work once we have stripped zoned volume though, won't it ?
> Why is not max_stripe_size set to zone size for a simple zoned btrfs volume ?
> 

My intention was to not support zoned volumes with this patch. However I missed 
the correct check in the function btrfs_stripe_size_show. The intent was to return
-EINVAL for zoned volumes. 

Any thoughts?

>>
>> 	return btrfs_show_u64(&max_stripe_size, NULL, buf);
>> }
>>
>> [...]
>>
>>> +	if (fs_info->fs_devices->chunk_alloc_policy == BTRFS_CHUNK_ALLOC_ZONED)
>>> +		return -EINVAL;
>>
>> Nit: As we can't mix zoned and non-zoned devices 'if (btrfs_is_zoned(fs_info))'
>> should do the trick here as well and is way more readable. 
>>
>>
> 
> 

  reply	other threads:[~2021-10-27  6:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-26 16:59 [PATCH] btrfs: sysfs: set / query btrfs stripe size Stefan Roesch
2021-10-26 18:08 ` Hugo Mills
2021-10-26 18:29 ` Josef Bacik
2021-10-27  6:28 ` Johannes Thumshirn
2021-10-27  6:51   ` Damien Le Moal
2021-10-27  6:58     ` Stefan Roesch [this message]
2021-10-27  7:09       ` Johannes Thumshirn
2021-10-27  7:19         ` Stefan Roesch
2021-10-27  7:37           ` Johannes Thumshirn
2021-10-27  7:20     ` Johannes Thumshirn

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=285f0f7f-a2df-7f23-2ba3-8ad3c12293ad@fb.com \
    --to=shr@fb.com \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=Naohiro.Aota@wdc.com \
    --cc=damien.lemoal@opensource.wdc.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