All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yu Kuai" <yukuai@fnnas.com>
To: "Reindl Harald" <h.reindl@thelounge.net>,
	 "Paul Menzel" <pmenzel@molgen.mpg.de>
Cc: <bugreports61@gmail.com>, <linux-raid@vger.kernel.org>,
	 <linan122@huawei.com>, <xni@redhat.com>,
	<regressions@lists.linux.dev>,
	 "Linus Torvalds" <torvalds@linux-foundation.org>,
	<yukuai@fnnas.com>
Subject: Re: Issues with md raid 1 on kernel 6.18 after booting kernel 6.19-rc1 once
Date: Wed, 17 Dec 2025 16:33:14 +0800	[thread overview]
Message-ID: <e8ed6876-7a27-4ef4-a4ea-841cf251f656@fnnas.com> (raw)
In-Reply-To: <2339e7f8-2369-4d77-a2fc-57b72dff6c94@thelounge.net>

Hi,

在 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/20251103125757.1405796-5-linan666@huaweicloud.com 
>>
>
> 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

  reply	other threads:[~2025-12-17  8:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-17  6:58 Issues with md raid 1 on kernel 6.18 after booting kernel 6.19rc1 once BugReports
2025-12-17  7:06 ` Yu Kuai
2025-12-17  7:13   ` BugReports
2025-12-17  7:17     ` Yu Kuai
2025-12-17  7:25       ` BugReports
2025-12-17  7:33       ` Issues with md raid 1 on kernel 6.18 after booting kernel 6.19-rc1 once Paul Menzel
2025-12-17  7:41         ` Yu Kuai
2025-12-17  8:02           ` Reindl Harald
2025-12-17  8:33             ` Yu Kuai [this message]
2025-12-17 13:07               ` Thorsten Leemhuis
2025-12-17 13:45                 ` Yu Kuai
2025-12-17 13:50                   ` Reindl Harald
2025-12-17 13:24   ` Issues with md raid 1 on kernel 6.18 after booting kernel 6.19rc1 once Li Nan
2025-12-18 10:41     ` Bugreports61
2025-12-18 14:54       ` Li Nan
2025-12-18 16:04         ` BugReports
2025-12-19  8:22           ` Li Nan

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=e8ed6876-7a27-4ef4-a4ea-841cf251f656@fnnas.com \
    --to=yukuai@fnnas.com \
    --cc=bugreports61@gmail.com \
    --cc=h.reindl@thelounge.net \
    --cc=linan122@huawei.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=regressions@lists.linux.dev \
    --cc=torvalds@linux-foundation.org \
    --cc=xni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.