On Fri, 27 Apr 2012 22:59:48 -0400 likewhoa <likewhoa@xxxxxxxxxxxxxxxx> wrote: > On 04/27/2012 10:55 PM, NeilBrown wrote: > > On Fri, 27 Apr 2012 22:37:29 -0400 likewhoa <likewhoa@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > >>> 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:
signature.asc
Description: PGP signature
