[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALTww29X5KizukDHpNcdeHS8oQ-vejwqTYrV5RFnOesZbFhYBQ@mail.gmail.com>
Date: Thu, 6 Nov 2025 22:56:59 +0800
From: Xiao Ni <xni@...hat.com>
To: yukuai@...as.com
Cc: Li Nan <linan666@...weicloud.com>, corbet@....net, song@...nel.org, hare@...e.de,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-raid@...r.kernel.org, yangerkun@...wei.com, yi.zhang@...wei.com
Subject: Re: [PATCH v9 4/5] md: add check_new_feature module parameter
On Thu, Nov 6, 2025 at 9:31 PM Yu Kuai <yukuai@...as.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.
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?
Regards
Xiao
>
> Thanks,
> Kuai
>
Powered by blists - more mailing lists