[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241112085327.00007de3@linux.intel.com>
Date: Tue, 12 Nov 2024 08:54:31 +0100
From: Mariusz Tkaczyk <mariusz.tkaczyk@...ux.intel.com>
To: Song Liu <song@...nel.org>
Cc: Yu Kuai <yukuai1@...weicloud.com>, linux-raid@...r.kernel.org,
linux-kernel@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com,
"yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH md-6.13] md: remove bitmap file support
On Thu, 7 Nov 2024 17:28:43 -0800
Song Liu <song@...nel.org> wrote:
> On Thu, Nov 7, 2024 at 5:03 PM Yu Kuai <yukuai1@...weicloud.com> wrote:
> >
> > Hi,
> >
> > 在 2024/11/08 7:41, Song Liu 写道:
> > > On Thu, Nov 7, 2024 at 5:02 AM Yu Kuai <yukuai1@...weicloud.com> wrote:
> > >>
> > >> From: Yu Kuai <yukuai3@...wei.com>
> > >>
> > >> 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@...wei.com>
> > >
> > > 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
Powered by blists - more mailing lists