On Sun, 25 Jan 2015 17:46:20 +0100 "Wesley W. Terpstra" <wesley@xxxxxxxxxxx>
wrote:
> On Sat, Jan 24, 2015 at 11:23 PM, Wesley W. Terpstra <wesley@xxxxxxxxxxx> wrote:
> >> First, it is obviously the last test in super_1_load that is rejecting
> >> the array. The superblock reports more sectors than are calculated, so
> >> the check
> >> if (sectors < le64_to_cpu(sb->data_size)) {
> >> fails.
> >
> > Thus, an alternative explanation could be that the the sb->data_size
> > was not updated after the reshape completed.
>
> I can confirm that this was the problem.
>
> I manually modified my super block using the attached quick hack.
> Thereafter I was able to reassemble the array and fsck everything
> successfully.
>
> I will try and see if I can reproduce the problem tomorrow. It's a
> pretty nasty bug to have a reshape complete and render your array
> unassemblable.
Thanks for all the details and analysis!!!
A v1.2 array normally has data from the data_offset all the way to the end of
the device (maybe rounded down to chunk size).
So you normally wouldn't be able to increase the data_offset from 5120 to
8192 unless you first reduced the --size of the array (having reduced the
size of any filesystem first).
Did you do that? That should have reduced sb->data_size appropriately.
If you did --grow the --size first, that should have reduced sb->data_size.
If you didn't the --grow --data-offset should have failed.
Obviously one of those 'should's didn't...
NeilBrown
Attachment:
pgpB2TNhYjxG4.pgp
Description: OpenPGP digital signature
