Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
	Stefan Roesch <shr@fb.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: Wed, 27 Oct 2021 15:51:38 +0900	[thread overview]
Message-ID: <9a0a442c-8409-3401-da85-9032259a7bc5@opensource.wdc.com> (raw)
In-Reply-To: <PH0PR04MB74165B2A0D395AD9A45310C79B859@PH0PR04MB7416.namprd04.prod.outlook.com>

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 ?

> 
> 	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. 
> 
> 


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2021-10-27  6:51 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 [this message]
2021-10-27  6:58     ` Stefan Roesch
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=9a0a442c-8409-3401-da85-9032259a7bc5@opensource.wdc.com \
    --to=damien.lemoal@opensource.wdc.com \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=Naohiro.Aota@wdc.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=shr@fb.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