On Tue, 12 Aug 2025 at 08:40, Xiao Ni <xni@xxxxxxxxxx> wrote: > > On Tue, Aug 12, 2025 at 2:32 AM Luca Boccassi <luca.boccassi@xxxxxxxxx> wrote: > > > > On Fri, 8 Aug 2025 at 09:07, Luca Boccassi <luca.boccassi@xxxxxxxxx> wrote: > > > > > > On Fri, 8 Aug 2025 at 07:40, Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote: > > > > 在 2025/08/08 13:28, Xiao Ni 写道: > > > > > I know it's not good to break mdadm by a kernel change. But sometimes > > > > > it needs userspace tool and kernel work together to fix a problem, > > > > > right? > > > > > Sorry for bringing the problem, and thanks for the suggestions. Any > > > > > more good suggestions? > > > > > > > > > > > > > Idealy, we should fix mdadm first, then after a release, fix kernel. > > > > Sadly the transition stage is missing now. :( > > > > > > > > If we want to just avoid this problem in kernel, what I can think of is > > > > adding a switch and mark it deprecated for now. And in new mdadm > > > > releases enable that switch, and after sometime, remove mdadm legacy > > > > code to stop array, and finally remove the deprecated switch in kernel > > > > then everyone will be happy :) > > > > > > Hi, > > > > > > As long as the change makes the current default behaviour backward > > > compatible, and the switch is used by mdadm to opt-in the new, > > > incompatible behaviour, then yes that sounds like a good solution, > > > thank you. > > > > Hi, > > > > Any update? RC1 was released with this regression. Any ETA on the fix? > > If it won't be ready soon, would it be possible to revert the change > > for now, until the fix is ready? Thanks! > > > > Hi > > I took two days for a regression test and sent the patch to the mail > list just now. That's great news, thank you!
