On Tue, 15 Mar 2011 12:45:19 +0100 Michael Gebetsroither <mich...@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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
