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

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)

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.
>