Re: raid10 issues after reorder of boot drives.

[likewhoa <likewhoa@weboperative.com>]

On 04/27/2012 11:23 PM, NeilBrown wrote:
> On Fri, 27 Apr 2012 22:59:48 -0400 likewhoa <likewhoa@weboperative.com> wrote:
>
>> On 04/27/2012 10:55 PM, NeilBrown wrote:
>>> On Fri, 27 Apr 2012 22:37:29 -0400 likewhoa <likewhoa@weboperative.com> wrote:
>>>
>>>> On 04/27/2012 08:35 PM, likewhoa wrote:
>>>>> I am not sure how to proceed now with the output that shows possible
>>>>> pairs as it won't allow me to setup all 8 devices on the array but only
>>>>> 4. Should I run the array creation with -x4 and set the available spare
>>>>> devicesor or just create the array as I can remember which was one pair
>>>>> from each controller. i.e /dev/sda3 /dev/sde3 ...?
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> ok I was able to recreate the array with correct order which I took from
>>>> my /dev/md0's --details output and was able to decrypt the luks mapping
>>>> but XFS didn't open and xfs_repair is currently doing the matrix. I will
>>>> keep this posted with updates.
>>> I hope the order really is correct.... I wouldn't expect xfs to find problems
>>> if it was...
>>>
>>>> Thanks again Neil.
>>>> WRT 3.3.3 should I just go back to 3.3.2 which seemed to run fine and
>>>> wait until there is a release of 3.3.3 that has fix?
>>> 3.3.4 has the fix and was just released.
>>> 3.3.1, 3.3.2 and 3.3.3 all have the bug.  It only triggers on shutdown and
>>> even then only occasionally.
>>> So I recommend 3.3.4.
>>>
>>> NeilBrown
>> The reason I believe it was correct was that 'cryptsetup luksOpen
>> /dev/md1 md1' worked. I really do hope that it was correct too because
>> after opening the luks mapping I assume there is no going back.
> Opening the luks mapping could just mean that the first few blocks are
> correct.  So the first disk is right but others might not be.
>
> There is going backup unless something has been written to the array.  Once
> that happens anything could be corrupted.  So if the xfs check you are  doing
> is read-only you could still have room to move.
>
> With a far=2 array, each first half of each device is mirrored on the second
> half.  So you can probably recover the ordering by finding which pairs match.
>
> The "Used Dev Size" is 902992896 sectors.  Half of that is 451496448
> or 231166181376 bytes.
>
> So to check if two devices are adjacent in the mapping you can try:
>
>  cmp --ignore-initial=0:231166181376 --bytes=231166181376 first-dev second-dev
>
> You could possibly use a smaller --bytes= number, at least on the first
> attempt.
> You a similar 'for' loop to before an use this command and it might tell you
> which pairs of devices are consecutive.  From that you should be able to get
> the full order.
>
> NeilBrown
>
I don't see why xfs_repair would write data unless it actually finds the
superblock but I am not sure so I will take my chances since it's still
searching for the secondary superblock now.