linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Li Nan <linan666@huaweicloud.com>
To: Xiao Ni <xni@redhat.com>, Li Nan <linan666@huaweicloud.com>
Cc: corbet@lwn.net, song@kernel.org, yukuai3@huawei.com,
	hare@suse.de, martin.petersen@oracle.com, bvanassche@acm.org,
	filipe.c.maia@gmail.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
	yangerkun@huawei.com, yi.zhang@huawei.com
Subject: Re: [PATCH v4 2/2] md: allow configuring logical_block_size
Date: Tue, 16 Sep 2025 14:33:09 +0800	[thread overview]
Message-ID: <dda37f0c-bf31-cc40-4c6e-9ad85333de9a@huaweicloud.com> (raw)
In-Reply-To: <CALTww28y7D32SAeoGgv2HjFJW471AtTD-SG0yxed4ZCJSOCHUw@mail.gmail.com>



在 2025/9/15 16:50, Xiao Ni 写道:
> On Mon, Sep 15, 2025 at 10:15 AM Li Nan <linan666@huaweicloud.com> wrote:
>>
>>
>>
>> 在 2025/9/15 8:33, Xiao Ni 写道:
>>> Hi Nan
>>>
>>> On Thu, Sep 11, 2025 at 3:41 PM <linan666@huaweicloud.com> wrote:
>>>>
>>>> From: Li Nan <linan122@huawei.com>
>>>>
>>>> Previously, raid array used the maximum logical_block_size (LBS) of
>>>> all member disks. Adding a larger LBS during disk at runtime could
>>>> unexpectedly increase RAID's LBS, risking corruption of existing
>>>> partitions.
>>>
>>> Could you describe more about the problem? It's better to give some
>>> test steps that can be used to reproduce this problem.
>>
>> Thanks for your review. I will add reproducer in the next version.
> 
> Thanks.
>>
>>>>
>>>> Simply restricting larger-LBS disks is inflexible. In some scenarios,
>>>> only disks with 512 LBS are available currently, but later, disks with
>>>> 4k LBS may be added to the array.
>>>>
>>>> Making LBS configurable is the best way to solve this scenario.
>>>> After this patch, the raid will:
>>>>     - stores LBS in disk metadata.
>>>>     - add a read-write sysfs 'mdX/logical_block_size'.
>>>>
>>>> Future mdadm should support setting LBS via metadata field during RAID
>>>> creation and the new sysfs. Though the kernel allows runtime LBS changes,
>>>> users should avoid modifying it after creating partitions or filesystems
>>>> to prevent compatibility issues.
>>>
>>> Because it only allows setting when creating an array. Can this be
>>> done automatically in kernel space?
>>>
>>> Best Regards
>>> Xiao
>>
>> The kernel defaults LBS to the max among all rdevs. When creating RAID
>> with mdadm, if mdadm doesn't set LBS explicitly, how does the kernel
>> learn the intended value?
>>
>> Gunaghao previously submitted a patch related to mdadm:
>> https://lore.kernel.org/all/3a9fa346-1041-400d-b954-2119c1ea001c@huawei.com/
> 
> Thanks for reminding me about this patch. First I still need to
> understand the problem. It may be a difficult thing for a user to


Thank you for your response.

Reproducer:
https://lore.kernel.org/all/3e26e8a3-e0c1-cd40-af79-06424fb2d54b@huaweicloud.com/

I will add it to messge log in the next version.

> choose the logcial block size. They don't know why they need to
> consider this value, right? If we only need a default value, the
> kernel space should be the right place?
> 

The scenario of our product is that they have a mix of 4k LBS and 512 LBS
disks. For most users, they do not need to modify the default values. This
is difficult to solve through default values.

> Regards
> Xiao
>>
>> --
>> Thanks,
>> Nan
>>
> 
> 
> .

-- 
Thanks,
Nan


      reply	other threads:[~2025-09-16  6:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-11  7:31 [PATCH v4 0/2] make logical_block_size configurable linan666
2025-09-11  7:31 ` [PATCH v4 1/2] md: prevent adding disks with larger logical_block_size to active arrays linan666
2025-09-12  3:18   ` Xiao Ni
2025-09-12  9:20     ` Li Nan
2025-09-11  7:31 ` [PATCH v4 2/2] md: allow configuring logical_block_size linan666
2025-09-11  8:05   ` Paul Menzel
2025-09-12  9:27     ` Li Nan
2025-09-15  0:33   ` Xiao Ni
2025-09-15  2:15     ` Li Nan
2025-09-15  8:50       ` Xiao Ni
2025-09-16  6:33         ` Li Nan [this message]

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=dda37f0c-bf31-cc40-4c6e-9ad85333de9a@huaweicloud.com \
    --to=linan666@huaweicloud.com \
    --cc=bvanassche@acm.org \
    --cc=corbet@lwn.net \
    --cc=filipe.c.maia@gmail.com \
    --cc=hare@suse.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=song@kernel.org \
    --cc=xni@redhat.com \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.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;
as well as URLs for NNTP newsgroup(s).