From: Andreas Klauer <Andreas.Klauer@metamorpher.de>
To: "Patrik Dahlström" <risca@powerlamerz.org>
Cc: Brad Campbell <lists2009@fnarfbargle.com>, linux-raid@vger.kernel.org
Subject: Re: Recover array after I panicked
Date: Tue, 25 Apr 2017 02:16:14 +0200 [thread overview]
Message-ID: <20170425001614.GA3936@metamorpher.de> (raw)
In-Reply-To: <727eeaf5-b856-305d-99b6-e42f3383b699@powerlamerz.org>
On Tue, Apr 25, 2017 at 01:00:47AM +0200, Patrik Dahlström wrote:
> 6 disk raid xor check: 84 ^ f6 ^ 87 ^ 96 ^ e1 ^ 82 == 0, OK
This should be the 6 disk raid area.
> 5 disk raid xor check: 46 ^ 73 ^ 6d ^ 06 ^ 5e == 0, OK
This should be the 5 disk raid area.
> 6 disk raid xor check: 46 ^ 73 ^ 6d ^ 06 ^ 5e ^ 00 == 0, OK
Still 5 disks... grow did not progess until here,
and the 6th disk is likely zero because it's new.
> But immediately before that, I can't get the xor sums to line up:
> 0xfaa287ffff: b0 ^ 6d ^ 13 ^ 1b ^ b7 != ae (62 actually), NOK
> This would mean that it's incorrect for both 5 and 6 disk raids.
Not too sure about this point.
If it up and died in mid-grow there might be a chunk that's wrong.
But that's a few kilobytes, not...
> That is a span of ~52 GB where I presumably can't get the checksums
> right. What does all this mean? What am I missing?
...well, it would make sense if a disk got kicked / went missing
and it progressed the reshape for another ~52GB afterwards.
If you still had your original md metadata the --examine would clear
that point up but unfortunately...
In a /dev/md that doesn't have that same disk as missing, this would
result in roughly ~260-320Gs of data that is garbage (because one drive
was not reshaped but the others were so every nth chunk is wrong).
You might still be able to survive that (if the raid6 <-> raid5 overlap
zone is larger than that - I didn't do the math, but at a progress of
17% of your 6T disks you've added about 1T? Might just work out).
So you might have these zones on your RAIDs
6DISK: ?G VALID-DATA : ~320G of GARBAGE : ?G 5DISK-WRONGOFFSET-NONSENSE
5DISK: ?G 6DISK-WRONGOFFSET-NONSENSE : ~260G of GARBAGE : ?G VALID DATA
And you're hoping the VALID DATA areas will overlap. They would if it
progressed far enough with all disks and not too far with one missing.
Or you just have to identify the questionable drive and kick it out.
You have some experimenteering to do :-|
(
Not sure if I'm still making sense at this point. Sorry.
)
Regards
Andreas Klauer
next prev parent reply other threads:[~2017-04-25 0:16 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-23 9:47 Recover array after I panicked Patrik Dahlström
2017-04-23 10:16 ` Andreas Klauer
2017-04-23 10:23 ` Patrik Dahlström
2017-04-23 10:46 ` Andreas Klauer
2017-04-23 11:12 ` Patrik Dahlström
2017-04-23 11:36 ` Wols Lists
2017-04-23 11:47 ` Patrik Dahlström
2017-04-23 11:53 ` Reindl Harald
2017-04-23 11:58 ` Roman Mamedov
2017-04-23 12:11 ` Wols Lists
2017-04-23 12:15 ` Patrik Dahlström
2017-04-24 21:04 ` Phil Turmel
2017-04-24 21:56 ` Patrik Dahlström
2017-04-24 23:35 ` Phil Turmel
2017-04-23 13:16 ` Andreas Klauer
2017-04-23 13:49 ` Patrik Dahlström
2017-04-23 14:36 ` Andreas Klauer
2017-04-23 14:45 ` Patrik Dahlström
2017-04-23 12:32 ` Patrik Dahlström
2017-04-23 12:45 ` Andreas Klauer
2017-04-23 12:57 ` Patrik Dahlström
2017-04-23 14:06 ` Brad Campbell
2017-04-23 14:09 ` Patrik Dahlström
2017-04-23 14:20 ` Patrik Dahlström
2017-04-23 14:25 ` Brad Campbell
2017-04-23 14:48 ` Andreas Klauer
2017-04-23 15:11 ` Patrik Dahlström
2017-04-23 15:24 ` Patrik Dahlström
2017-04-23 15:42 ` Andreas Klauer
2017-04-23 16:29 ` Patrik Dahlström
2017-04-23 19:21 ` Patrik Dahlström
2017-04-24 2:09 ` Brad Campbell
2017-04-24 7:34 ` Patrik Dahlström
2017-04-24 11:04 ` Andreas Klauer
2017-04-24 12:13 ` Patrik Dahlström
2017-04-24 12:37 ` Andreas Klauer
2017-04-24 12:54 ` Patrik Dahlström
2017-04-24 13:39 ` Andreas Klauer
2017-04-24 14:05 ` Patrik Dahlström
2017-04-24 14:21 ` Andreas Klauer
2017-04-24 16:00 ` Patrik Dahlström
2017-04-24 23:00 ` Patrik Dahlström
2017-04-25 0:16 ` Andreas Klauer [this message]
2017-04-25 8:44 ` Patrik Dahlström
2017-04-25 9:01 ` Andreas Klauer
2017-04-25 10:40 ` Patrik Dahlström
2017-04-25 10:51 ` Patrik Dahlström
2017-04-25 11:08 ` Andreas Klauer
2017-04-25 11:37 ` Patrik Dahlström
2017-04-25 12:41 ` Andreas Klauer
2017-04-25 18:22 ` Wols Lists
2017-04-27 19:57 ` Patrik Dahlström
2017-04-27 23:12 ` Andreas Klauer
2017-04-28 7:11 ` Patrik Dahlström
2017-04-28 9:52 ` Andreas Klauer
2017-04-28 10:31 ` Patrik Dahlström
2017-04-28 11:39 ` Andreas Klauer
2017-04-28 22:46 ` Patrik Dahlström
2017-04-29 9:56 ` Andreas Klauer
2017-05-02 13:08 ` Patrik Dahlström
2017-05-02 13:11 ` Brad Campbell
2017-05-02 15:49 ` Anthony Youngman
2017-04-25 23:01 ` Patrik Dahlström
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170425001614.GA3936@metamorpher.de \
--to=andreas.klauer@metamorpher.de \
--cc=linux-raid@vger.kernel.org \
--cc=lists2009@fnarfbargle.com \
--cc=risca@powerlamerz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox