On Thu, 7 Nov 2024 17:28:43 -0800 Song Liu <song@xxxxxxxxxx> wrote: > On Thu, Nov 7, 2024 at 5:03 PM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote: > > > > Hi, > > > > 在 2024/11/08 7:41, Song Liu 写道: > > > On Thu, Nov 7, 2024 at 5:02 AM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote: > > >> > > >> From: Yu Kuai <yukuai3@xxxxxxxxxx> > > >> > > >> The bitmap file has been marked as deprecated for more than a year now, > > >> let's remove it, and we don't need to care about this case in the new > > >> bitmap. > > >> > > >> Signed-off-by: Yu Kuai <yukuai3@xxxxxxxxxx> > > > > > > What happens when an old array with bitmap file boots into a kernel > > > without bitmap file support? > > > > If mdadm is used with bitmap file support, then kenel will just ignore > > the bitmap, the same as none bitmap. Perhaps it's better to leave a > > error message? > > Yes, we should print some error message before assembling the array. > > > And if mdadm is updated, reassemble will fail. I would be great if mdadm can just ignore it too. It comes from config file, so simply you can ignore bitmap entry if it is different than "internal" or "clustered". You can print error however you must do it somewhere else (outside config.c), otherwise user would be always prompted about that on every config read - probably we don't need to make it such noise but maybe we should (user may not notice change if we are not screaming it loud). I have no opinion here. The first rule is always data access- we should not break that if possible. I think case I think it is possible to keep them assembled. > > I think we should ship this with 6.14 (not 6.13), so that we have > more time testing different combinations of old/new mdadm > and kernel. WDYT? Later is better because it decreases possibility that someone would met the case with new kernel and old mdadm, where probably some ioctl/sysfs writes fails will be observed. I would say that we should wait around one year after removing it from mdadm. That is preferred by me. I will merge Kuai changes soon, before the release. I think it is valuable to have it blocked in new mdadm release. Mariusz
