linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Song Liu <song@kernel.org>
Cc: Yu Kuai <yukuai1@huaweicloud.com>,
	linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
	yi.zhang@huawei.com, yangerkun@huawei.com,
	"yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH md-6.13] md: remove bitmap file support
Date: Tue, 12 Nov 2024 08:54:31 +0100	[thread overview]
Message-ID: <20241112085327.00007de3@linux.intel.com> (raw)
In-Reply-To: <CAPhsuW4tcXqL3K3Pdgy_LDK9E6wnuzSkgWbmyXXqAa=qjAnv7A@mail.gmail.com>

On Thu, 7 Nov 2024 17:28:43 -0800
Song Liu <song@kernel.org> wrote:

> On Thu, Nov 7, 2024 at 5:03 PM Yu Kuai <yukuai1@huaweicloud.com> wrote:
> >
> > Hi,
> >
> > 在 2024/11/08 7:41, Song Liu 写道:  
> > > On Thu, Nov 7, 2024 at 5:02 AM Yu Kuai <yukuai1@huaweicloud.com> wrote:  
> > >>
> > >> From: Yu Kuai <yukuai3@huawei.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@huawei.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

      parent reply	other threads:[~2024-11-12  7:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07 12:59 [PATCH md-6.13] md: remove bitmap file support Yu Kuai
2024-11-07 23:41 ` Song Liu
2024-11-08  1:03   ` Yu Kuai
2024-11-08  1:28     ` Song Liu
2024-11-08  1:33       ` Yu Kuai
2024-11-08  5:15       ` Dragan Milivojević
2024-11-08  6:07         ` Yu Kuai
2024-11-08 22:19           ` Dragan Milivojević
2024-11-09  1:43             ` Yu Kuai
2024-11-09  2:15               ` Dragan Milivojević
2024-11-11  2:04                 ` Yu Kuai
2024-11-11 11:59                   ` Dragan Milivojević
2024-11-11 13:02                     ` Yu Kuai
2024-11-11 14:07                       ` Dragan Milivojević
2024-11-13  1:18                         ` Yu Kuai
2024-11-13  1:25                           ` Dragan Milivojević
2024-11-12  7:54       ` Mariusz Tkaczyk [this message]

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=20241112085327.00007de3@linux.intel.com \
    --to=mariusz.tkaczyk@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=song@kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai1@huaweicloud.com \
    --cc=yukuai3@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).