Re: [PATCH v9 4/5] md: add check_new_feature module parameter

["Yu Kuai" <yukuai@fnnas.com>]

Hi,

在 2025/11/6 22:56, Xiao Ni 写道:
> On Thu, Nov 6, 2025 at 9:31 PM Yu Kuai <yukuai@fnnas.com> wrote:
>> Hi,
>>
>> 在 2025/11/6 21:15, Xiao Ni 写道:
>>> In patch05, the commit says this:
>>>
>>> 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.
>>>
>>> So it only can specify logical block size when creating an array. In
>>> the case you mentioned above, in step3, the array will be assembled in
>>> new kernel and the sb->pad3 will not be set, right?
>> No, lbs will be set to the value array actually use in metadata, otherwise
>> data loss problem will not be fixed for the array with different lbs from
>> underlying disks, this is what we want to fix in the first place.
> But the case you mentioned is to assemble an existing array in a new
> kernel. The existing array in the old kernel doesn't set lbs. So the
> sb->pad3 will be zero when assembling it in the new kernel.

Looks like you misunderstood the patch, lbs in sb->pad3 will be updated to the
real lbs when array is assembled in the new kernel. Set lbs in metadata is
necessary to avoid data loss.

And please noted this patch is required to be backported to old kernel to
make it possible that array with default lbs can be assembled again in old
kernel.

>
> And as planned, we will not support --lbs (for example) for the `mdadm
> --assemble` command.
>
> The original problem should be fixed by specifying lbs when creating
> an array (https://www.spinics.net/lists/raid/msg80870.html). Maybe we
> should avoid updating lbs when adding a new disk？

I don't understand, lbs modification should be forbidden once array is
created, it's only allowed to be updated before the array is running the
first time.

>
> Regards
> Xiao
>> Thanks,
>> Kuai
>>