On Thu, Sep 5, 2024 at 7:07 PM Xiao Ni <xni@xxxxxxxxxx> wrote: > [...] > > Hi Song > > I rewrite the comments like this: > > Now reshape supports two ways: with backup file or without backup file. > For the situation without backup file, it needs to change data offset. > It doesn't need systemd service mdadm-grow-continue. So it can finish > the reshape job in one process environment. It can know the new level > from mdadm --grow command and can change to new level after reshape > finishes. > > For the situation with backup file, it needs systemd service > mdadm-grow-continue to monitor reshape progress. So there are two process > environments. One is mdadm --grow command whick kicks off reshape. It > doesn't wait reshape to finish and wake up mdadm-grow-continue service. > Two is the service. But it doesn't know the new level. Because in the > first step, it doesn't sync the information to kernel space. So the new > level which reads from superblock is wrong. > > In kernel space mddev->new_level is used to record the new level when > doing reshape. This patch tries to add a new interface to help mdadm > can update new level and sync it to metadata. So it can read the right > new level when mdadm-grow-continue starts. And it can change to the new > level after reshape finishes. > > Reproduce steps: > mdadm -CR /dev/md0 -l6 -n4 /dev/loop[0-3] > mdadm --wait /dev/md0 > mdadm /dev/md0 --grow -l5 --backup=backup > cat /proc/mdstat > Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [raid10] > md0 : active raid6 loop3[3] loop2[2] loop1[1] loop0[0] > > Test case 07changelevels from mdadm regression tests can trigger this > problem. Applied to md-6.12 with a commit log based on this version. Thanks, Song
