Re: [PATCH 01/10] mdadm/Grow: Update new level when starting reshape

[Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>]

On Tue, 3 Sep 2024 08:34:46 +0800
Xiao Ni <xni@redhat.com> wrote:

> On Mon, Sep 2, 2024 at 6:10 PM Mariusz Tkaczyk
> <mariusz.tkaczyk@linux.intel.com> wrote:
> >
> > On Mon, 2 Sep 2024 11:50:13 +0200
> > Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> wrote:
> >  
> > > Hi Xiao,
> > > Thanks for patches.
> > >
> > > On Wed, 28 Aug 2024 10:11:41 +0800
> > > Xiao Ni <xni@redhat.com> wrote:
> > >  
> > > > Reshape needs to specify a backup file when it can't update data offset
> > > > of member disks. For this situation, first, it starts reshape and then
> > > > it kicks off mdadm-grow-continue service which does backup job and
> > > > monitors the reshape process. The service is a new process, so it needs
> > > > to read superblock from member disks to get information.  
> > >
> > > Looks like kernel is fine with reset the same level so I don't see a risk
> > > in this change for other scenarios but please mention that.
> > >  
> >
> > Sorry, I didn't notice that it is new field. We should not update it if it
> > doesn't exist. Perhaps, we should print message that kernel patch is
> > needed?  
> 
> We can merge this patch set after the kernel patch is merged. Because
> this change depends on the kernel change. If the kernel patch is
> rejected, we need to find another way to fix this problem.

We have to mention kernel commit in description then.


Let say that it is merged, we should probably notify user,
"hey your kernel is missing the kernel patch that allow this functionality to
work reliably, issue may occur". What do you think? Is it valuable?

Thanks,
Mariusz