All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.