Re: [PATCH 018 of 29] md: Support changing rdev size on running arrays.

[Markus Hochholdinger <Markus@hochholdinger.net>]

Hi,

Am Mittwoch, 10. November 2021, 14:09:53 CET schrieb Markus Hochholdinger:
> Am Samstag, 24. März 2012, 21:47:15 CET schrieb Markus Hochholdinger:
> > it's been a long time, but today I tried again and had success!
> > Am 28.06.2008 um 01:41 Uhr schrieb Neil Brown <neilb@suse.de>:
> > > On Friday June 27, Markus@hochholdinger.net wrote:
> > > > Am Freitag, 27. Juni 2008 08:51 schrieb NeilBrown:
> > > > > From: Chris Webb <chris@arachsys.com>
> > [..]
> > > You don't want to "mdadm --grow" until everything has been resized.
> > > First lvresize one disk, then write '0' to the .../size file.
> > > Then do the same for the other disk.
> > > Then "mdadm --grow /dev/mdX --size max".
> > it works for me, if I do:
> >   echo 0 > /sys/block/md2/md/rd0/size
> >   mdadm --grow /dev/md2 --size=max
> >   # till here, nothing happens
> >   echo 0 > /sys/block/md2/md/rd1/size
> >   mdadm --grow /dev/md2 --size=max
> >   # rebuild of the added space begins
> This has been working for me till at least kernel 4.19.x and I first
> recognized it not working anymore with kernel 5.10.x . So inbetween
> something changed regarding the resize and grow of md raid1 with superblock
> version 1.0. The grow still works and a rebuild is done, but afterwards the
> superblock isn't created/moved to the new end of the devices. The raid1
> works until you stop it, but you won't be able to re-assemble it
> (re-creating works). While re-creating I recognized the grown filesystem
> (after the raid1 was grown) was too large (fsck complained).
> I already tracked it down to the version of the metadata/superblock. With
> version 1.0 (superblock at the end) the above fails and it looks like the
> superblock on the grown device is somehow there but with wrong informations
> (mdadm --zero-superblock has removed something while mdadm -D .. tells me,
> there's no superblock).
> All works fine with superblock version 1.2 (superblock at the beginning).
> Any ideas what could have changed so the grow feature for raid1 with
> superblock version 1.0 isn't working anymore?
> For now the workaround is to really remove a grown device from the raid1 and
> do a full rebuild before re-adding the other grown device.
> I'll test the different kernel versions to see, where/when this feature was
> lost.

It is working es (I) expected till at least kernel 5.4.158.

It is not working with 5.10.x till 5.15.1.

On my old systems (kernel <= 5.4.x) after resizing one component
  mdadm -E /dev/xvda2
is able to see the moved superblock only after
  echo 0 > /sys/block/md2/md/rd0/size

On new systems (kernel >= 5.10.0) it doesn't matter if I issue
  echo 0 > /sys/block/md2/md/rd0/size
mdadm -E keeps complaining about no superblock on the grown device.
(The bitmap was removed before the echo 0 and I tried to remove the bitmap at 
all before resizing, still the same issue.)

It's only possible to remove the changed device and add with a full rebuild. 
But this isn't possible, if both devices were resized before. mdadm complains 
about no metadata available, no matter what I do while the md raid1 is still 
running (where is the superblock updated on the disks then?).


> > If I do only:
> >   echo 0 > /sys/block/md2/md/rd0/size
> >   echo 0 > /sys/block/md2/md/rd1/size
> >   mdadm --grow /dev/md2 --size=max
> > 
> > nothing will change.
> > As I understand, with "echo 0" md sees the new size and only with --grow
> > the superblock will be moved.
> > I'm doing this with 2.6.32-5-xen-686 within Debian (squeeze) 6.0.
> > Many thanks to you and all the other linux-raid developers for this
> > feature! I'm very happy about this :-)


-- 
Mfg

Markus Hochholdinger