Re: raid10 issues after reorder of boot drives.

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]