On Tue, Sep 3, 2024 at 3:34 PM Mariusz Tkaczyk <mariusz.tkaczyk@xxxxxxxxxxxxxxx> wrote: > > On Tue, 3 Sep 2024 08:34:46 +0800 > Xiao Ni <xni@xxxxxxxxxx> wrote: > > > On Mon, Sep 2, 2024 at 6:10 PM Mariusz Tkaczyk > > <mariusz.tkaczyk@xxxxxxxxxxxxxxx> wrote: > > > > > > On Mon, 2 Sep 2024 11:50:13 +0200 > > > Mariusz Tkaczyk <mariusz.tkaczyk@xxxxxxxxxxxxxxx> wrote: > > > > > > > Hi Xiao, > > > > Thanks for patches. > > > > > > > > On Wed, 28 Aug 2024 10:11:41 +0800 > > > > Xiao Ni <xni@xxxxxxxxxx> 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? Hi Mariusz It makes sense. I'll add this in V2 once kernel patch is merged. Regards Xiao > > Thanks, > Mariusz >
