Re: Issues with md raid 1 on kernel 6.18 after booting kernel 6.19-rc1 once

Hi,

在 2025/12/17 21:07, Thorsten Leemhuis 写道:
> Bringing Jens in (and Son Liu, too), as the patches that cause this
> afaics went through his tree -- so he is the right point of contact in
> the hierarchy.
>
> FWIW, thread starts here:
> https://lore.kernel.org/all/[email protected]/
>
> Problem rough and short afaiui: mdraids assembled with 6.19-rc1 can not
> be mounted with 6.18 any more; see below for details. That to my
> understanding of things is not okay, even if it could be fixed by
> backporting a patch (which is a option here)

AFAIK, possible options:
1) always set lbs for arrays for new kernel, and backport the patch for
old kernels so that users can still assemble the array.(current option)
2) only set lbs by default for new array, for assembling the array still
left the lbs field unset, in this case the data loss problem is not fixed,
we should also print a warning and guide users to set lbs to fix the problem,
with the notification the array will not be assembled in old kernels.
3) revert the new feature to set lbs for mdraids.

>
> Ciao, Thorsten
>
> On 12/17/25 09:33, Yu Kuai wrote:
>> 在 2025/12/17 16:02, Reindl Harald 写道:
>>> Am 17.12.25 um 08:41 schrieb Yu Kuai:
>>>>>>> We'll have to backport following patch into old kernels to make
>>>>>>> new arrays to assemble in old kernels. ....
>>>>>>>
>>>>>>> The md array which i am talking about was not created with kernel
>>>>>>> 6.19, it was created sometime in 2024.
>>>>>>>
>>>>>>> It was just used in kernel 6.19 and that broke compatibility with
>>>>>>> my 6.18 kernel.
>>>>>> I know, I mean any array that is created or assembled in new kernels
>>>>>> will now have lsb field stored in metadata. This field is not
>>>>>> defined in old kernels and that's why array can't assembled in old
>>>>>> kernels, due to unknown metadata.
>>>>>>
>>>>>> This is what we have to do for new features, and we're planning to
>>>>>> avoid the forward compatibility issue with the above patch that I
>>>>>> mentioned.
>>>>> Is there really no way around it? Just testing a new kernel and being
>>>>> able to go back must be supported in my opinion, at least between one
>>>>> or two LTS versions.
>>>> As I said, following patch should be backported to LTS kernels to
>>>> avoid the problem.
>>>> https://lore.kernel.org/linux-raid/[email protected]
>>>>
>>> that's nothing you can rely on - yo can write as many pachtes as you
>>> will but if and when they are included in random binary kernels is not
>>> controllable
>>>
>>> the current situation is somebody tests a new kernel and after that
>>> his RAID got unrevertable changed and can't be used with the previous
>>> kernel
>>>
>>> that's not expectable nor acceptable
>> I'll explain a bit more about the lbs.
>>
>> There is a long long term problem from day one, and reported several times, that array data
>> can be broken when:
>>    - user add a new disk to the array;
>>    - some member disks are failed;
>>
>> lbs in metadata is used to fix this problem. However, mdraid is designed to refuse new metadata
>> fields, this doesn't make sense but that's the fact.
>>
>> Any array that is assembled or created in new kernels will have lbs filed stored in metadata, to
>> prevent the data loss problem. I know we're not expecting forward compatibility issue, but I don't
>> think this is not acceptable. We'll provide a solution but we can't guarantee for any binary
>> kernels.
>>
-- 
Thansk,
Kuai