Bug#618463: mdadm: Mdadm grow of Raid1 destroys metadata

[NeilBrown]

On Tue, 15 Mar 2011 12:45:19 +0100 Michael Gebetsroither <michael at mgeb.org>
wrote:

> Package: mdadm
> Version: 2.6.7.2-3
> Severity: grave
> Justification: causes non-serious data loss
> 
> Hi,
> 
> mdadm --grow /dev/mdX --size=max shreded the second raid1 array here.
> 
> Commands where as following:
> lvextend -L +10G vda/opt
> lvextend -L +10G vdb/opt

md was not made aware of these changes to the sizes of the individual devices,
so

> mdadm --grow /dev/md2 --size=max

This caused mdadm to do nothing as it always "knew" that all of the available
space on the devices was already in use.

> 
> # mdadm -E /dev/vda/opt
> mdadm: No md superblock detected on /dev/vda/opt.
> # mdadm -E /dev/vdb/opt
> mdadm: No md superblock detected on /dev/vdb/opt.

mdadm looks for the metadata need the end of the device.  As the end of the
device has moved, it can no-longer see the metadata


> 
> After mdadm --stop /dev/md2 the array couldn't be reassambled.
> 
> To fix this problem i simply recreated the array with:
> # mdadm --create --assume-clean /dev/md2 -l1 -n2 /dev/vda/opt /dev/vdb/opt
> mdadm: /dev/vda/opt appears to contain an ext2fs file system
>     size=10485696K  mtime=Tue Feb 22 12:28:24 2011
> mdadm: /dev/vdb/opt appears to contain an ext2fs file system
>     size=10485696K  mtime=Tue Feb 22 12:28:24 2011
> Continue creating array? yes
> mdadm: array /dev/md2 started.

Excellent!


What this is really a 'wishlist' issue.
You would like mdadm to notice that the devices have changed size, and tell
md, or maybe would like md to be able to be told immediately when it happens.
Or something like that.

Certainly a good idea.

NeilBrown