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.
>>
>>
>
>
next prev parent 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